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.