RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Erik Österlund]

Hi Stuart,

I am okay with just changing the signature of the prologue to have both 
src and dst for now. This is after all what x86, SPARC, PPC and S390 all do.
So making that small change unifies the way we do it today on the 
various different platforms.

I can volunteer to improve the interface to be even more flexible as 
discussed, in a separate follow-up RFE.
But I don't see any reason why you would have to wait for that.

Thanks,
/Erik

On 2019-05-20 11:17, Stuart Monteith wrote:
> Hello Roman,
>      I'm not sure what the time frame for JDK-822340 , but I'd like ZGC
> for aarch64 to be in JDK 13. I've opened JDK-8224187 with just the
> changes to the array_prologue signature, as I'll at least need that
> for ZGC.
>
> BR,
>     Stuart
>
> On Fri, 17 May 2019 at 16:52, Roman Kennke <rkennke at redhat.com> wrote:
>> Hi Erik
>>
>> That is fine by me. We have 3 cases lined up now that require a more
>> flexible interface for arraycopy, and what you propose sounds
>> reasonable. But it requires work, and right now I'm terribly
>> side-tracked. So this has to wait a little bit from my side. If anybody
>> is free to pick it up, feel free. I suggest to just use the existing
>> issue to cover it:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8223240
>>
>> Roman
>>
>>> 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
>>>>>>
>>>>>>