[aarch64-port-dev ] RFR: 8224187 Refactor arraycopy_prologue to allow ZGC read barriers on arraycopy

[Stuart Monteith]

Hello,
   I've reopened JDK-8224187, as 8223240 is another discussion. I
don't have committer's writes to push commit 8224187.

BR,
 Stuart

On Tue, 21 May 2019 at 09:36, Per Liden <per.liden at oracle.com> wrote:
>
> Hi Roman,
>
> I have to agree. This is not a about adding a band-aid for ZGC, it's
> about fixing aarch64's barrier set.
>
> I don't think this should be conflated with the other patch you
> proposed, since that's is a different review/discussion to solve a
> different problem.
>
> cheers,
> Per
>
> On 2019-05-20 17:53, Erik Österlund wrote:
> > Hi Roman,
> >
> > I don't think I would call it a band-aid for ZGC to add the src
> > parameter to the prologue. That is just harmonizing the arraycopy
> > interface model we already have on all platforms today, to do on AArch64
> > what the other platforms have always been doing since the API was
> > introduced, since before ZGC was integrated.
> > However, having the actual copying being performed sometimes inside of
> > the public pre-barrier, which may or may not throw a checkcast
> > exception, seems like a very different beast to jam into the public
> > interface.
> > Apart from being a rather ugly abstraction, I don't feel like I can
> > assess if that approach is correct or not (w.r.t. checkcast exceptions)
> > without seeing the proposed shenandoah code that uses it. In your patch
> > I just see passing around of values that are never used. I also don't
> > know how that will play with windows that has an ABI-adapter from
> > windows ABI to Sys-V used to wrap the arraycopy code. The ABI wrapper
> > saves windows callee saved registers on the thread, assuming that the
> > copying code itself does not nest... I don't know if it still does not
> > nest with this approach, as the ABI conversion scope is set up outside
> > the barrier set calls, and inside of the prebarrier in the runtime that
> > calls arraycopy back into the stub code again, I think the result on
> > windows is that it might overwrite the callee saved registers in a nasty
> > and intermittent way that is hard to reproduce.
> >
> > /Erik
> >
> > On 2019-05-20 12:40, Roman Kennke wrote:
> >> I'd rather see Erik's proposal implemented to make the GC generate the
> >> whole path to begin with. Otherwise we'd band-aid for ZGC now, and later
> >> have to band-aid again for Shenandoah. See discussion for JDK-8223240
> >> and in your aarch64 on ZGC thread.
> >>
> >> Roman
> >>
> >>> Hello,
> >>>     On aarch64 the signature for
> >>> barrierSetAssembler::arraycopy_prologue needs to be changed in order
> >>> accept the source as well as the destination array for ZGC's barriers.
> >>>
> >>> The bug:
> >>>   https://bugs.openjdk.java.net/browse/JDK-8224187
> >>> and the patch:
> >>>    http://cr.openjdk.java.net/~smonteith/8224187/webrev.0/
> >>>
> >>>
> >>> BR,
> >>>     Stuart
> >>>
> >