Aarch64 port for ZGC, so far

[Per Liden]

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
>