RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Roman Kennke]

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:

https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-May/025693.html

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.

Roman


> 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
>>>>>>>
>>>>>>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190520/0d68de94/signature.asc>