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

[Roman Kennke]

Am 18.10.18 um 15:34 schrieb 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.

Ah yes, right. Another/additional option would be to pass
ACCESS_ARRAYCOPY decorator or such to indicate that this load/store
relates to an arraycopy.

Roland, what do you think? Would something like this work?

Roman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181018/f9c17e96/signature.asc>