RFR: 8233506: ZGC: the load for Reference.get() can be converted to a load for strong refs

Erik Österlund erik.osterlund at oracle.com
Mon Nov 11 07:58:16 UTC 2019


Hi Tobias,

> On 11 Nov 2019, at 08:12, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi Erik,
> 
>> On 08.11.19 16:15, erik.osterlund at oracle.com wrote:
>>> On 11/8/19 9:38 AM, Tobias Hartmann wrote:
>>> Do we still need that logic with your change?
>> 
>> Nope! :) Because the access nodes have their barrier data populated before transformation,
>> describing the semantics of the produced access, we don't care what GVN gives us after
>> transformation. Whatever it gives us has the correct semantics for the corresponding access that
>> produced it.
> 
> Can we remove that code then? I mean the one you referred to with "We already have code that tries
> to determine if the load we got out from the GVN transformation looks like a load that was created
> in the BarrierSetC2 factory function".

Ahh. To be clear: I meant the code in the backend that first calls e.g. BarrerSetC2::load_at_resolved, and then checks in ZBarrierSetC2, if the resulting raw_access() is really a load before sprinkling barriers. This change deletes all that.

>> Sure, will file another RFE for that.
>> Regarding the assert, it's not obvious what it would look like, since the assert in the
>> transformation code has to know exactly what nodes are expected to have GC data. For example, a
>> LoadP might be used to read any pointer, including but not limited to oops. And some oops don't need
>> barriers like the threadOop due to being processed in safepoints. So given a LoadP node for example,
>> I don't know if we can determine whether it should or should not have GC data.
> 
> Right, that doesn't seem feasible.
> 
> Ship it!

Thanks Tobias!

/Erik

> Best regards,
> Tobias



More information about the hotspot-compiler-dev mailing list