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

[Erik Österlund]

Hi Roman,

On 2018-10-18 15:22, Roman Kennke 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.
> Yeah, this is a very good point. arraycopy replacement by load/store
> series is not the same as emitting 'standalone' loads or stores: we know
> we don't need RB and WB on the source and target arrays (we already have
> that), and we know we don't need certain other things (e.g. SATB
> pre-barrier) because of dst being new (in case of clone). Seems
> tricky/impossible to do this generically. I'd rather have a special API
> for this particular arraycopy optimization.

Even though I never suggested adding an API for the store unless you 
feel like it, I guess I should mention that you can represent that you 
don't want SATB barrier with the IS_DEST_UNINITIALIZED decorator, which 
is how this is already done in the rest of the VM.
As for the redundant resolve for read/write barriers, won't you elide 
them anyway in a subsequent optimization pass? If not, I guess we could 
have a RESOLVE_NONE decorator as I think we have discussed before. But I 
really thought these redundant barriers were eliminated anyway.

Thanks,
/Erik

> Roman
>