[9] RFR (S): 8134918: C2: Type speculation produces mismatched unsafe accesses

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Apr 15 18:52:47 UTC 2016


Looks good.

Thanks,
Vladimir

On 4/15/16 11:25 AM, Vladimir Ivanov wrote:
> Thanks for the feedback, Vladimir.
>
> Updated version:
>    http://cr.openjdk.java.net/~vlivanov/8134918/webrev.01/
>
> Additional changes:
>
>    * alias type doesn't differentiate between byte[] & boolean[]; use address type to narrow the basic type;
>
>> Next assert should be at the beginning of method:
>> +     assert(type != T_OBJECT || !unaligned, "unaligned access not
>> supported with object type");
> Fixed.
>
>> Fix Copyright year in the test.
> Fixed.
>
>> There is no PIT link in the bug report.
> Added.
>
> Best regards,
> Vladimir Ivanov
>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/14/16 9:53 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8134918/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8134918
>>>
>>> Type speculation can produce mismatched unsafe accesses.
>>>
>>> It injects a guard based on profile data and then propagate type info
>>> down to the users. If there's an unsafe access, it can become
>>> mismatched w.r.t. profile data being used.
>>>
>>> It happens even for valid usages. If an unsafe access always matches
>>> memory location at runtime, the code produced by type speculation in
>>> that case is effectively dead.
>>>
>>> What cause problems are unsafe OOP accesses (U.putObject()/getObject()
>>> on non-OOP locations).
>>>
>>> The fix is to avoid intrinsification of problematic accesses. Type
>>> speculation injects precise type information, which is available
>>> during intrinsification.
>>>
>>> We could try to support mismatched unsafe object accesses instead, but
>>> I don't see any value in that.
>>>
>>> Testing: JPRT, pit-hs-comp (in progress).
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov


More information about the hotspot-compiler-dev mailing list