RFR: JDK-8221766: Load-reference barriers for Shenandoah

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Apr 3 17:24:52 UTC 2019


Good (C2 part).

Thanks,
Vladimir

On 4/3/19 10:13 AM, Roman Kennke wrote:
>> I don't think it should be part of this cleanup.
> 
> Fair enough.
> I have run several tests today, and removing the is_Phi() call doesn't seem to negatively impact Shenandoah.
> 
> Updated webrevs:
> Incremental:
> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.01.diff/
> Full:
> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.01/
> 
> Ok now?
> 
> Thanks,
> Roman
> 
> 
>> Please, file separate RFE to push this change with separate review and testing.
>>
>> Thanks,
>> Vladimir
>>
>> On 4/3/19 4:18 AM, Roland Westrelin wrote:
>>>
>>> Hi Vladimir,
>>>
>>>> opto/loopnode.cpp new is_Phi check was added. Please, explain.
>>>
>>> When we expand barriers, if we find a null check nearby we move the
>>> barrier close to the null check so there's a better chance of converting
>>> it to an implicit null check. That happens as part of a pass of loop
>>> opts. I think that's where that change comes from but I don't remember
>>> the details. In general we need the control that's assigned to a load to
>>> not be too conservative.
>>>
>>> Anyway, that change is not required for correctness. But it looks
>>> reasonable to me.
>>>
>>> Roland.
>>>



More information about the hotspot-gc-dev mailing list