A few years ago the developers of Hazelcast Jet decided to try out the different GC alternatives available at the time. The result was this blog-series from 2020 and the results for ZGC looked very promising. Three years have passed since then and a lot more work has gone into ZGC. It became production ready in JDK 15, concurrent stack scanning was added in JDK 16 and now, in JDK 21, generational support has been added making it even more suitable for low latency workloads. In this post we look at one of the Hazelcast Jet experiments and see how Generational ZGC performs.
Hazelcast Jet on Generational ZGC
GC progress from JDK 8 to JDK 17
JDK 17 has been out for a few months and it’s not just packed with new language features. The performance boost compared to older JDK versions is also really significant. It becomes especially clear when compared to the previous LTS releases, JDK 8 and JDK 11. Much of the improved performance comes from new features and optimizations in the JVM and in this post the focus will be on the improvements done in the area of garbage collection.
Large pages and Java
I’ve recently spent a lot of time in memory reservation code of the JVM. It started out because we got an external contribution to enable use of multiple large page sizes for Linux. To do this in a good way some other things had to be refactored first. While taking this trip down memory lane I realized that doing a short summary of how large pages are used by the JVM might be an interesting read.
Improving G1 out-of-the-box performance
A few weeks back a set of benchmark results comparing JDK 8 and JDK 14 were published by Phoronix. The SPECjbb® 2015 results presented in that report really caught our eyes. They don’t compare to what we have seen in our own testing and this needed some investigation. Before digging in to what we found, I’ll start off with some background on one big difference between JDK 8 and JDK 14.