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

[Vladimir Ivanov]

Yes, it can. But I don't think it's common. Otherwise, we would hit the 
assert much earlier (and not with a focused test case).

Broad on-heap/off-heap accesses usually end up as 
TypeRawPtr::BOTTOM/TypeOopPtr::BOTTOM.

I planned to investigate removal of the check separately.

Best regards,
Vladimir Ivanov

On 5/6/16 2:40 AM, Vladimir Kozlov wrote:
> Thank you for info. Will this fix cause performance issue? It looks like
> common case for me.
>
> Thanks,
> Vladimir K
>
> On 5/5/16 3:12 PM, Vladimir Ivanov wrote:
>> Thanks, Vladimir.
>>
>>> Looks good. What actual alias type in such case?
>>
>> Both adr_type & alias_type are:
>>
>>     java/lang/Object+12 * [narrow]
>>
>> And LibraryCallKit::classify_unsafe_addr() returns Type::OopPtr for it.
>>
>> Best regards,
>> Vladimir Ivanov
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/5/16 11:48 AM, 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