Aarch64 port for ZGC, so far
stuart.monteith at linaro.org
Fri Nov 30 12:22:33 UTC 2018
You're right, I was halfway through hedging my bets. One thing
that concerns me is the longevity of a solution that uses the ignored
bits. I recently moved the ZGC's coloured bits to the top 4 bits to
avoid the up and coming Memory Tagging Extensions (MTE) in ARMv8.5 -
they currently use bits 56 to 59, and so I'd be clear if I used bits
60 to 63. See: https://developer.arm.com/docs/ddi0596/a/a64-shared-pseudocode-functions/aarch64-functions-pseudocode#impl-shared.AddressWithAllocationTag.2_2
I've come across an issue where zMarkStackEntry is assuming the top
two bits of an address aren't significant, whereas they are. This
results in references losing some of their colour.
As I see it I either ignore MTE for now, take it into account and
alter zMarkStackEntry to drop some bits between, say, bits 52 to 54,
or to somehow have aarch64 able to use multimapping or VA-masking.
But in conclusion, I won't leave that code as it is.
On Fri, 30 Nov 2018 at 08:06, Per Liden <per.liden at oracle.com> wrote:
> Hi Stuart,
> On 11/23/18 12:46 PM, Stuart Monteith wrote:
> > Hello,
> > I thought I'd update where I am with ZGC. The C1 code seems to be
> > mostly working. I had an issue where ZMarkStack was stripping off the
> > top two bits of the 64-bit addresses, which is where I've put the
> > thread colours to avoid tags in MTE.
> > I've added some support for C2 to the ZGC code. There are some
> > issues, however, with the graph.
> > As before the 64-bit Literal oops support patch is needed:
> > http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/
> > The patchset is here:
> > http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/
> Thanks for the update. Just did a quick scan over the patch, and noticed
> a couple of things.
> The check added here seems to belong in zArguments.cpp. We might even
> want to introducing a zArguments_<arch>.cpp in the future, but
> zArguments.cpp works for now.
> With VA-masking enabled, the functionality provided by the above files
> should not be needed since you can just map anonymous memory.
> > To run with ZGC enabled, you'll need to pass:
> > -XX:+UnlockExperimentalVMOptions
> > -XX:+UseZGC
> > I've included a test case here:
> > http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/
> > Which can be executed with or without "-XX:+UseBarriersForVolatile" to
> > reproduce two different errors.
> > With that option I see:
> > # Internal Error
> > (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859,
> > tid=17048
> > # assert(C->node_arena()->contains(s->_leaf) ||
> > !has_new_node(s->_leaf)) failed: duplicating node that's already been
> > matched
> > and without I see:
> > # Internal Error
> > (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436,
> > tid=3503
> > # assert(ldst->trailing_membar() != __null) failed: expected trailing membar
> > This is due to a combination of the graph generated in
> > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier
> > handling in aarch64.ad that Roland recently changed in "8209420: Track
> > membars for volatile accesses so they can be properly optimized". This
> > is easily triggered in the C2Example.java file I've linked to above,
> > where calls to Unsafe.compareAndSwapObject provoke the issue.
> > I'm trying to unpick the problems with the graph - I've uploaded the
> > replay, hs_err and ideal graph xml files of runs with and without
> > +UseBarriersForVolatile, in case someone could provide some insight.
> > BR,
> > Stuart
More information about the zgc-dev