Aarch64 port for ZGC, so far

Stuart Monteith stuart.monteith at linaro.org
Fri Nov 23 11:46:33 UTC 2018

  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:

The patchset is here:

To run with ZGC enabled, you'll need to pass:

I've included a test case here:

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,
  #  assert(C->node_arena()->contains(s->_leaf) ||
!has_new_node(s->_leaf)) failed: duplicating node that's already been

and without I see:
 #  Internal Error
(/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436,
 #  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.


More information about the zgc-dev mailing list