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

[Vladimir Ivanov]

Thanks, Vladimir.
I'm pushing the fix into jdk9/dev.

Best regards,
Vladimir Ivanov

On 7/21/16 8:12 PM, Vladimir Kozlov wrote:
> 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