RFR: JDK-8214527 AArch64: ZGC for Aarch64

Per Liden per.liden at oracle.com
Tue May 21 11:05:09 UTC 2019


Hi Stuart,

On 05/17/2019 04:28 PM, Stuart Monteith wrote:
> Hello,
>     This patch implements ZGC for AArch64. Unlike the previous set of
> patches, this duplicates the x86 multimapping scheme rather than using
> the Aarch64 TBI feature, where the top 8 bits are ignored by the
> hardware. I didn't measure any conclusive performance problems using
> multimapping. It would necessitate changes to SA, JNI, and wasn't
> going to be compatible with Graal or JVMCI in general until they were
> also able to switch to 64-bit literals dynamically. In addition, there
> are up and coming features in the AArch64 architecture that exploit
> the TBI area that we should keep open, such as MTE (Memory Tagging
> Extensions) that open the door to lightweight hardware ASAN. With MTE
> using 4 of the 8 bits, and ZGC and MTE perhaps needing more than 4
> bits, future conflict looks likely.
> 
> JTreg testing hasn't demonstrated any significant differences from x86
> ZGC in my testing.
> 
> The behaviour should be the same as is expected from x86_64, including
> for the behaviour with command line arguments. Currently ZGC requires
> -XX:+UnlockExperimentalVMOptions, that should be the case for AArch64
> this release. If x86_64 were to do have ZGC designated as not
> experimental, we must ensure it still applies for ZGC on AArch64.

I don't think there's a good way to declare the a flag product on one 
platform, and experimental on another. But I guess 
zArguments::initialize_platform() on aarch64 could check for and 
warn/exit if UnlockExperimentalVMOptions is false.

> 
> The associated bug is:
>      https://bugs.openjdk.java.net/browse/JDK-8214527
> The patchset is:
>        http://cr.openjdk.java.net/~smonteith/8214527/webrev.0/

src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad
-----------------------------------------
I'd suggest you break out the duplicate parts of these into a function, 
like we have done in z_x86.ad.


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
src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp 

--------------------------------------------------------------------
I'd would like to deduplicate most of these at some point, but I'm ok 
with doing that after this has been merged, as we might need/want to 
slice this slightly differently (to cater for the different syscall 
numbers etc).


cheers,
Per

> 
> There is a patch contributed by Roland Westerlin required for fixing
> memory barriers,
>    http://cr.openjdk.java.net/~smonteith/zgc-mm/20190430/membar/
> I'll follow up with a separate RFR patch to address that.
> 
> Thanks,
>     Stuart
> 



More information about the hotspot-gc-dev mailing list