RFR(XS): 8216549: Mismatched unsafe access to non escaping object fails

Vladimir Kozlov vladimir.kozlov at oracle.com
Sun Jan 13 22:05:46 UTC 2019


+1

Thanks,
Vladimir K.

On 1/11/19 11:49 AM, Vladimir Ivanov wrote:
> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 11/01/2019 01:16, Roland Westrelin wrote:
>>
>> http://cr.openjdk.java.net/~roland/8216549/webrev.00/
>>
>> test1(), test2() and test3() perform an unsafe access with a mismatched
>> access.
>>
>> test1() compiles to an unschedulable graph and causes the compiler to
>> crash. The memory input of the load from a non escaping allocation
>> initially points to a membar but is set to bypass the membar while
>> control stays set to the membar. The load is not eliminated because it's
>> a mismatched memory access, an anti dependence is added between the
>> membar and the load and the graph is unschedulable.
>>
>> test2() and test3() return wrong results: the access is mismatched and
>> misaligned, it's given its own alias by c2 but the MergeMem right after
>> the allocation only points to the allocation for actual fields of the
>> newly allocated object. So the load memory input is set to the memory
>> state on method entry and the load is optimized as zero.
>>
>> I simply propose to make non escaping allocations with mismatched
>> accesses to be non scalar replaceable.
>>
>> Roland.
>>


More information about the hotspot-compiler-dev mailing list