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