[aarch64-port-dev ] Aarch64 port for ZGC, so far
stuart.monteith at linaro.org
Fri Nov 30 11:13:18 UTC 2018
I've opened https://bugs.openjdk.java.net/browse/JDK-8214527 - do
you think I've tagged it correctly?
lea() is used in the barrier code - and sometimes it can be as simple
as a register move, see zBarrierSetAssembler_aarch64.cpp for examples.
I did consider putting the test into vm_version_aarch64.cpp - but that
seemed inappropriate. Per has suggested putting it into
zArguments.cpp, so I'll revise it to do that.
On Fri, 30 Nov 2018 at 01:53, White, Derek <Derek.White at cavium.com> wrote:
> Hi Stuart,
> I have some superficial comments:
> Can we add a bug for AArch64 support for ZGC? If you're swamped I can do it.
> - Address::lea() & LIR_Assembler::leal():
> - I'm not sure where they are used, but if they can be tested separately, it might be good to pull out as a non-ZGC fix.
> - Probably better to move this into cpu/aarch64/vm_version_aarch64.cpp, along with all of the other aarch64 flag setting in get_processor_features().
> - This is also ugly, but at least it's not ugly in shared code.
> - Is this change necessary?
> I'll try to look at the real parts later...
> - Derek
> ps. We're going through an email switch here, so you may get duplicate/similar versions of some email.
> From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> on behalf of Stuart Monteith <stuart.monteith at linaro.org>
> Sent: Friday, November 23, 2018 6:46 AM
> To: aarch64-port-dev; zgc-dev at openjdk.java.net; Roland Westrelin
> Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far
> External Email
> 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