RFR: JDK-8214527 AArch64: ZGC for Aarch64

Roman Kennke rkennke at redhat.com
Mon May 20 12:03:28 UTC 2019

Hi Erik,

This is great!

To me the question is, would changing the interfaces a little more to
also add a 'Register klass, Label& exit' parameters as temporary measure
be acceptable too? Like I proposed here:


and that is, for the same reasons. We would like to make progress on a
bunch of dependend issues and get it into jdk13, but can't currently
afford a full-out reworking of the corresponding GC interfaces? It also
seems like a less-risky measure overall.


> 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

More information about the zgc-dev mailing list