[9] RFR (S): 8134918: C2: Type speculation produces mismatched unsafe accesses
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Fri Apr 15 18:25:26 UTC 2016
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