[aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far

[Stuart Monteith]

Thanks for the heads up Per. The JTREG testing has shown some
interesting errors with ZGC - I'm not sure whether all of these are to
do with tagging, but I'll be comparing them against ZGC without
tagging.

I'm very conscious of the June 13th deadline. Would a JEP be
appropriate for ZGC on aarch64? I'm not sure of the precedent, as I'd
expect it to just be "same as on x86".

One item to follow is, of course, class unloading.

BR,
  Stuart

On Wed, 1 May 2019 at 20:05, Per Liden <per.liden at oracle.com> wrote:
>
> Hi Stuart,
>
> On 04/30/2019 07:36 PM, Stuart Monteith wrote:
> > I've made a patchset with multi-mapping for aarch64, which is
> > literally a copy from x86. It doesn't require the 64bit literal
> > addresses patch, as the bits all fit within 48 bits:
> >      http://cr.openjdk.java.net/~smonteith/zgc-mm/20190430/
> >
> > There is also an updated patchset for the tagged pointers, with a fix
> > for the JNI "Critical" functions to mask out the tags:
> > http://cr.openjdk.java.net/~smonteith/zgc/20190430/
> >
> > These patchsets apply to the tip today, so they take into account the
> > new 4/8/16TB heap limits Per introduced.
> >
> > I'm currently regression testing, and benchmarking with/without
> > tagging. With tags there are 64-bit literals that ought to have a
> > negative effect on performance, and with multimapping there might be
> > some impact from the TLB. Having said that, the impact is expected to
> > be small on the TLB as Per explained.
> >
> > Once I've settled on an approach, I'll post RFRS - I'd really like for
> > ZGC for Aarch64 to get into OpenJDK for JDK 13.
>
> Sounds good. Just a heads up that there are two things that I think we
> want merged before the aarch64 port goes in. The first is JEP 351
> (uncommit). With multi-mapping, you'll get uncommit support for aarch64
> for free. With tagged pointers, some additional work will be needed in
> ZPhysicalMemoryBacking for aarch64. The second thing is Nils' work to
> improve/simplify the C2 barriers. That will affect ZGC's ad-file, but
> there shouldn't be too much work to adapt to that.
>
> My best guess at this time is that both of these things will be merged
> in the near future (JEP 351 will hopefully be targeted for 13 by end of
> tomorrow).
>
> Btw, if you go with multi-mapping, then we'll just move the copied files
> from os_cpu/linux_x86 to os/linux. And you can of course always go with
> multi-mapping first, and switch to using tagging at some point later (or
> vice versa for that matter).
>
> cheers,
> Per
>
> >
> > BR,
> >     Stuart
> >
> > On Mon, 15 Apr 2019 at 17:28, Stuart Monteith
> > <stuart.monteith at linaro.org> wrote:
> >>
> >> Thanks Per, I've not encountered any issues so far with that. With the
> >> fix to JNI, I expect ZGC should be functioning properly now... until
> >> the next edge-case when it is not.
> >>
> >> This is my current set of patches:
> >>     http://cr.openjdk.java.net/~smonteith/zgc/20190415/
> >>
> >> It was built on tip from this morning. Meanwhile, I'll work on a patch
> >> for multi-map ZGC for comparison.
> >>
> >> BR,
> >>    Stuart
> >>
> >>
> >> On Mon, 15 Apr 2019 at 16:33, Per Liden <per.liden at oracle.com> wrote:
> >>>
> >>> On 04/15/2019 05:25 PM, Andrew Haley wrote:
> >>>> On 4/15/19 3:57 PM, Stuart Monteith wrote:
> >>>>>      If I understand this correctly, siginfo_t would contain the
> >>>>> faulting address with the tag wiped. The ucontext would still contain
> >>>>> the full 64-bit registers, unmolested. I've asked internally, but that
> >>>>> is how I've interpreted it.
> >>>>
> >>>> That sounds sensible.
> >>>
> >>> Also note that depending on what this oop is used for in the signal
> >>> handler, you might not need the tag bits (they typically are only useful
> >>> for ZGC). But if you really do need them, you can call
> >>> ZAddress::good(oop) to slap the bits on again.
> >>>
> >>> cheers,
> >>> Per