[9] RFR (XS): 8155781: C2: opaque unsafe access triggers an assert

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Jul 21 17:09:26 UTC 2016

Thanks, Vladimir. Updated the fix in place.

>> Updated version:
>>   http://cr.openjdk.java.net/~vlivanov/8155781/webrev.01/
>> I haven't pushed the initial fix yet, since I started looking into
>> removing the checks. Unfortunately, recent migration
>> of j.u.c to VarHandles made the problematic code shape much more
>> frequent. I was asked to push the fix directly into
>> jdk9/dev to reduce the noise in test results.
>> It turned out LibraryCallKit::inline_unsafe_load_store() doesn't need
>> the check (no special cases for "wide" accesses),
>> so I removed it.
> It was assert which triggers error. Can you explain more why you don't
> need check there (and revert to native call)?

inline_unsafe_access() inspects alias_type->adr_type() to decide whether 
to issue a membar or not. It expects "unique" addresses and BOTs when it 
decides how to proceed.

inline_unsafe_load_store() doesn't need "wide" memory accesses to have 
BOT type. It always issues membars. So, the assert is too strong for it.

> BTW in this method null_check(receiver) call should be after the check
> mismatched object accesses. Otherwise it will be left in the graph.

Good point. I moved the check down.

Best regards,
Vladimir Ivanov

> Thanks,
> Vladimir
>> I'll address the check in LibraryCallKit::inline_unsafe_access()
>> separately (filed JDK-8162101), since I have to push it
>> into hs-comp to avoid merge conflicts during hs -> dev integration.
>> Testing: JPRT (-testset hotspot), RBT (hs-tier0-comp; in progress).
>> Thanks!
>> Best regards,
>> Vladimir Ivanov
>> [1] https://bugs.openjdk.java.net/browse/JDK-8162101
>> On 5/5/16 9:48 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8155781
>>> The following code hits an assert in
>>> LibraryCallKit::inline_unsafe_access() during compilation of the
>>> following code:
>>>     int test(Object o) {
>>>         return UNSAFE.getInt(o, F_OFFSET);
>>>     }
>>> It baffles the compiler since such shape can be used to access both
>>> on-heap and off-heap memory (due to double-register addressing mode).
>>> The proposed fix is to convert the asserts into guards which revert to
>>> native calls in such cases.
>>> Testing: JPRT, RBT (hs-tier0-comp).
>>> Thanks!
>>> Best regards,
>>> Vladimir Ivanov

More information about the hotspot-compiler-dev mailing list