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

[Vladimir Ivanov]

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