[aarch64-port-dev ] Aarch64 port for ZGC, so far

[White, Derek]

Hi Stuart,


Thanks, bug looks good.


Per's suggestion is fine with me.


- Derek

________________________________
From: Stuart Monteith <stuart.monteith at linaro.org>
Sent: Friday, November 30, 2018 6:13 AM
To: White, Derek
Cc: aarch64-port-dev; zgc-dev at openjdk.java.net; Roland Westrelin
Subject: Re: [aarch64-port-dev ] Aarch64 port for ZGC, so far

Hi Derek,
   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.

Thanks,
    Stuart

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.
>
> cpu/aarch64/assembler_aarch64.cpp:
> cpu/aarch64/c1_LIRAssembler_aarch64.cpp:
>  - 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.
>
> share/gc/shared/gcArguments.cpp:
>  - 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.
>
> share/gc/z/c2/zBarrierSetC2.cpp:
>  - 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
>
> 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/
>
> 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