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

[Vladimir Kozlov]

On 7/21/16 6:49 AM, Vladimir Ivanov wrote:
> 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)?

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

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