Previously I have done some posts about Shenandoah, and now it is time to talk about Oracle’s ZGC.

ZGC has an algorithm similar to Shenandoah (in terms of concurrence GC) only it uses coloured pointers to mark the objects, and that demands 64bits, so it doesn’t have 32bits of ZGC, necessary for the reference colouring. In comparison to Shenandoah’s additional one level of abstraction (forwarding pointer) that adds one words (+the other two already in OpenJDK). The tradeoff used to be the footprint, because for each object you add one more word (warning: this is true for Shenandoah1, in Shenandoah2, it uses the mark word for the forwarding pointer, so then there is no more footprint). Of course, Shenandoah it aims for very small pauses, i.e. sub-millisecond, handle of high heap and scalable pauses. It is available for JDK 11 on Windows, Linux 64, macOS and Linux/Aarch architectures.

This is a big thing is the tradeoff Oracle’s ZGC took his 64 bit implementation, so no 32bits. I don’t think ZGC has a degradation mode (or pacing mechanism) as Shenandoah does have, meaning it will not stall the threads of the application to make the GC finish the job (it will add latency as consequence, although invisible – 42:00).

Like G1GC, and much of contrary to CMS, it does not have that many flags to set as well. As Shenandoah you can play/tune it a bit, with basic initial heap size, number of concurrent GC threads, NUMA – JDK 17 feature – Huge and large pages. On some versions one can set AlwaysPreTouch.