Aarch64 port for ZGC, so far

Stuart Monteith stuart.monteith at linaro.org
Mon Dec 3 18:00:32 UTC 2018


Hi Per,
   I've moved the logic to zArguments for enabling Use64BitLiteralOops
- it sits much nicer there, thanks.

I've removed the zBacking* code - but just one question. Am I correct
in thinking that ZPhysicalMemoryBacking::try_expand(size_t, size_t)
can simply unconditionally return the new_capacity? There is no
backing file that requires extending, and the pages will have already
been allocated in the address space, albeit not actually physically.

Thanks,
    Stuart

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.
>
> src/hotspot/share/gc/shared/gcArguments.cpp
> -------------------------------------------
> 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.
>
>
> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
> --------------------------------------------------------------------
> With VA-masking enabled, the functionality provided by the above files
> should not be needed since you can just map anonymous memory.
>
> cheers,
> Per
>
> >
> > 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 mailing list