RFR(M): 8212243: More gc interface tweaks for arraycopy and some other smaller changes in preparation for Shenandoah

[Erik Österlund]

Hi Roland,

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);
> pre_barrier();
> 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?

Thanks,
/Erik

> Roland.