RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Stuart Monteith]

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