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

Roman Kennke rkennke at redhat.com
Wed Apr 3 17:13:04 UTC 2019

> 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:

Ok now?


> 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 build-dev mailing list