ZGC & AArch64
stuart.monteith at linaro.org
Wed Mar 28 15:31:01 UTC 2018
After Ed and I spoke with Per and Stefan at FOSDEM I've started
working on seeing what is necessary to get ZGC working on the Aarch64
backend. To be clear, this is the hotspot/cpu/aarch64 backend rather
than hotspot/cpu/arm backend.
I have just some observations and questions so far:
1. The address space used by ZGC is impressive - 17TB on my laptop.
However, you need to make sure your kernel is configured for 48-bit
virtual address space. I've currently hobbled ZGC a little to work
within the 42-bit VA. - basically using 39-bits rather than 42-bits as
the base addresses.
2. I'm basing my work on the SPARC port and the Linux x86 port. The
top 8-bits on aarch64 can be used as tag bits, and so that's where I'm
putting the "colours" - much like SPARC.
The os_cpu code is mostly derived from linux_x86, however. I've
removed the multi-mapping as that is unnecessary.
3. If this code gets ported on further platforms, we'll need to look
at refactoring the code. There will be a lot of redundancy. I'll
follow what you are doing for now, until aarch64 is in an acceptable
4. How active is the SPARC port? I've largely been taking my cues
from that port in the backend, rather than the OS code, and it would
be good to know if there are issues doing that.
5. I expected ZAddressBadMask to be held in Universe - is this to
ease rebasing? Ordinarily we'd retrieve such values through Universe::
6. Do you expect signal handlers to play a part in ZGC in the future?
It is something to watch on aarch64, as the tag bits will get stripped
under most circumstances.
I currently have it building, and I can run a GC benchmark on
interpreter mode, until hitting an issue with a references to a oop in
an unallocated ZPage. Running the same code on x86 completes just
More information about the zgc-dev