JDK-8236179 : C1 register allocation failure with T_ADDRESS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,8-aarch64,11,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-12-18
  • Updated: 2021-03-25
  • Resolved: 2019-12-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 15 Other
11.0.7Fixed 13.0.4Fixed 14Fixed 15 b03Fixed openjdk8u252Fixed
Related Reports
Relates :  
Description
In Shenandoah, we generate a call with one argument type T_ADDRESS (it's supposed to pass a pointer):

The problem manifested as a crash when running jcstress on Windows x86_64. Looking at the dump in a debugger it was apparent that it was something to do with the LRB code; some inspection revealed that there was an access violation when trying to do the CAS operation on the reference location after we determined the new location of the object. The reference address was indeed bogus, and I tracked down where it was coming from. Here is some code from the caller (Intel syntax ahead):

00000261`9beaf4da 488b4978         mov     rcx,qword ptr [rcx+78h]

00000261`9beaf4de 488b11           mov     rdx,qword ptr [rcx]

00000261`9beaf4e1 488d09           lea     rcx,[rcx]

00000261`9beaf4e4 48898c24b8010000 mov     qword ptr [rsp+1B8h],rcx

00000261`9beaf4ec 488bca           mov     rcx,rdx

00000261`9beaf4ef 8b9424b8010000   mov     edx,dword ptr [rsp+1B8h]

00000261`9beaf4f6 49baa0139ecef87f0000 mov r10,offset jvm!ShenandoahRuntime::load_reference_barrier_native (00007ff8`ce9e13a0)

00000261`9beaf500 41ffd2           call    r10

 

The second argument (which goes in *DX) for the load_reference_barrier_native is the load address. I noticed in the code above that, in the process of moving that value around, we stored it as 64-bit to the stack but then restored it as a 32-bit value when we put it in EDX. And sure enough, when I look at the memory in that location, there are a few extra bits which go with the address to make it valid.

As far as I know, it is only exposed by Shenandoah because that is the only code that generates something in C1 with T_ADDRESS.
Comments
Fix request (13u): The original change applies cleanly, passes tier1 and tier2 tests.
03-06-2020

Fix Request (8u) Critical fix for Shenandoah 8u downstream, and important fix in general. Patch does not apply cleanly to 8u due to missing platform support. 8u RFR (reviewed by phh): https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011165.html
17-02-2020

While working with this patch, I noticed it is not Shenandoah-specific. For example, Cassandra would enter the T_ADDRESS path for CRC32 intrinsics like this: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/6021152f9ff3/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp#l991 V [libjvm.so+0x4b351f] FrameMap::map_to_opr(BasicType, VMRegPair*, bool)+0x52f V [libjvm.so+0x4adc9e] FrameMap::c_calling_convention(BasicTypeArray const*)+0x24e V [libjvm.so+0x534297] LIRGenerator::do_update_CRC32(Intrinsic*)+0x4a7 V [libjvm.so+0x51589c] LIRGenerator::walk(Instruction*)+0x10c V [libjvm.so+0x52ba0b] LIRItem::set_instruction(Instruction*)+0x2b V [libjvm.so+0x5216b2] LIRGenerator::do_StoreField(StoreField*)+0x362 V [libjvm.so+0x49d9f8] StoreField::visit(InstructionVisitor*)+0xe8 V [libjvm.so+0x5155a4] LIRGenerator::do_root(Instruction*)+0x84 V [libjvm.so+0x515767] non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x67 V [libjvm.so+0x4e075e] BlockList::iterate_forward(BlockClosure*)+0x7e V [libjvm.so+0x4a74fb] Compilation::emit_lir()+0x4fb V [libjvm.so+0x4aa102] Compilation::compile_java_method()+0x692 V [libjvm.so+0x4aa4da] Compilation::compile_method()+0x7a V [libjvm.so+0x4aabd1] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*)+0x381 V [libjvm.so+0x4ab691] Compiler::compile_method(ciEnv*, ciMethod*, int)+0x171 V [libjvm.so+0x717f5e] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd8e V [libjvm.so+0x7197f8] CompileBroker::compiler_thread_loop()+0x958 V [libjvm.so+0x11dcf38] JavaThread::thread_main_inner()+0x1d8 V [libjvm.so+0x11dd287] JavaThread::run()+0x307 V [libjvm.so+0xe89832] java_start(Thread*)+0x102 C [libpthread.so.0+0x76db] start_thread+0xdb
10-02-2020

Fix Request jdk11u Critical fix for Shenandoah. Tested in jdk/jdk and already backported to jdk14. Applies almost cleanly (only one c1_FrameMap_arm.cpp hunk needs to get inserted manually due to unrelated context change from JDK-8209093).
10-01-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649 User: mdoerr Date: 2019-12-20 18:51:44 +0000
20-12-2019