[aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far
stuart.monteith at linaro.org
Tue Apr 30 17:36:08 UTC 2019
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:
There is also an updated patchset for the tagged pointers, with a fix
for the JNI "Critical" functions to mask out the tags:
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.
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:
> It was built on tip from this morning. Meanwhile, I'll work on a patch
> for multi-map ZGC for comparison.
> 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
More information about the zgc-dev