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

[Vladimir Kozlov]

Thank you for explanation. Looks good.

Thanks,
Vladimir

On 7/21/16 10:09 AM, Vladimir Ivanov wrote:
> 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