[aarch64-port-dev ] RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Stuart Monteith]

Thanks Erik.
I've uploaded:
   http://cr.openjdk.java.net/~smonteith/8224187/webrev.0/
for:
 https://bugs.openjdk.java.net/browse/JDK-8224187

I'll send out a separate RFR for that.

I've updated the ZGC patch to rely on 8224187:
   http://cr.openjdk.java.net/~smonteith/8214527/webrev.1/

BR,
   Stuart

On Mon, 20 May 2019 at 10:26, Erik Österlund <erik.osterlund at oracle.com> wrote:
>
> 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
> >>>>>>
> >>>>>>
>