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

[Vladimir Kozlov]

Thanks. Consider it is reviewed.

Vladimir K

On 5/5/16 5:00 PM, Vladimir Ivanov wrote:
> 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