RFR(M): 8212243: More gc interface tweaks for arraycopy and some other smaller changes in preparation for Shenandoah
erik.osterlund at oracle.com
Thu Oct 18 12:48:50 UTC 2018
On 2018-10-18 14:23, Roland Westrelin wrote:
>> So basically, you could make a new C2PostParseTimeAccess (name?!) that
>> you wrap this information in, and send it through the
>> BarrierSetC2::load_at backend.
>> Similar how there is a GraphKit::access_load_at helper for baking the
>> context object, you can have a helper (somewhere at your convenience)
>> for baking the C2PostParseTimeAccess.
> So you're suggesting an implementation of load and store that would work
> after parsing. We don't know how to do that in general. Arraycopy
> happens to be a special case where can emit the right barriers and
> that's why it has a special entry point.
> An object field load for us is:
> a' = rb(a);
> v = a'.f
> an object field store is:
> b' = wb(b);
> b'.f = wb(v);
> We have no way today of emitting the pre_barrier after parsing. In the
> case of this patch, we don't need the pre_barrier because the copy is to
> a newly allocated object.
> The load_store barrier for arraycopy is wb(v) only because the rb(a) and
> wb(b) are emitted at parse time right before the arraycopy.
> So what you're suggesting would be to move that stuff under a generic
> api which would be quite a bit more work and would actually not be
> generic because we have no way of implementing the generic api today.
I'm not suggesting adding support for an operation not used by any GC,
including Shenandoah. In other words, I am not suggesting that you add a
post parse-time write barrier that nobody uses. If we want to make that
symmetric another day, and use the IS_DEST_UNINITIALIZED decorator to
denote this is a new allocation requiring new pre-barrier, like we do
everywhere else in HotSpot, we can do that. But I understand if you do
not have the time to do that now and it is not required by any GC, and
hence probably won't make anyone happier. It would make me a bit happier
though I guess. The context is what you are adding - which is an
explicit load barrier for clone only. It has been a goal to not have
explicit load or store barriers.
So basically, rather than making a load and then attaching a load
barrier explicitly, use a load_at API that bakes the memory, control,
and whether reshaping is allowed, and perform the load with a load_at
function that goes through the same BarrierSetC2::load_at API as other
things, and attach the load barrier in the backend as required. At the
point where the load is generated, you either generate a parse-time load
that figures out control and memory, or you make a load with already
provided control and memory.
The need for these load barriers for clones is generic and may be used
by both ZGC and Shenandoah.
What do you think?
More information about the hotspot-compiler-dev