RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Erik Österlund]

Hi,

I still do believe it's better to let the GC override both the barriers 
and the accesses. In fact this is the way we consistently deal with all 
access calls, except arraycopy: the GC sprinkles barriers as they wish 
and calls the basic access in the appropriate places.
By doing this for arraycopy as well, the structure will be more clear, 
and it will be more flexible for the GC. Not just in theory, but in a 
way that is actually useful in reality as well. Rickard has for example 
played around with materializing wide bad masks, and bulk applying the 
load barrier in the copying loop, which showed great benefit. But it 
fell short exactly because we did not have the right interface in place 
to allow that.

Thanks,
/Erik

On 2019-05-17 17:05, Roman Kennke wrote:
> That's actually going in the same direction of what I already proposed:
>
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-May/025693.html
>
> We may want to pick up that discussion. Last thing I heard was that Erik
> suggested to broaden the proposed API changes to let the GC own the
> whole arraycopy stub generation. I.e. instead of:
>
> GC-interface-prologue
> actual arraycopy (without barriers)
> GC-interface-epilogue
>
> make one call to:
>
> GC-interface-arraycopy
>
> and let that generate prologue, copy and epilogue, or something totally
> different.
>
> The variant that I proposed was to keep the current structure, but allow
> the prologue to skip the body:
>
> GC-interface-prologue (possibly jump to exit)
> actual arraycopy (without barriers)
> GC-interface-epilogue
> exit: ...
>
> I didn't have time to follow-up on that yet, but I definitely want to.
>
> WDYT?
>
> Roman
>
>> Thanks for looking Aleksey.  I'll generate a separate patch.
>>
>> Are you happy that I deliberately left arraycopy_epilogue as it was?
>>
>> On Fri, 17 May 2019 at 15:41, Aleksey Shipilev <shade at redhat.com> wrote:
>>> On 5/17/19 4:28 PM, Stuart Monteith wrote:
>>>> The patchset is:
>>>>        http://cr.openjdk.java.net/~smonteith/8214527/webrev.0/
>>> I think that the extension of arraycopy_prologue interface is better to be handled and tested
>>> separately, to avoid surprises. GC interface should give us clean specific-GC-only patches for
>>> specific-GC features.
>>>
>>> -Aleksey
>>>
>>>