Optimizing Cloud Native Java, 2nd Edition

Chapter 5. Advanced Garbage Collection

In the last chapter, we introduced the basic theory of Java garbage collection and the conceptually simplest production collector (Parallel). From that starting point, we will move forward to introduce some of the theory of modern Java garbage collectors. After that, we will introduce the default garbage collector (G1) used by HotSpot (and GraalVM).

In general, for most workloads, G1 will be sufficient. However, there are a number of scenarios where the unavoidable tradeoffs that GC represents will guide the engineer’s choice of collector. So, we will also consider some more rarely seen collectors. These are:

• Shenandoah

• Z Garbage Collector (ZGC)

• Balanced

• Legacy HotSpot collectors

Note that not all of these collectors are used in the HotSpot virtual machine—​the Balanced collector we will be discussing is a collector from Eclipse OpenJ9.

Tradeoffs and Pluggable Collectors

One aspect of the Java platform that beginners don’t always immediately recognize is that while Java has a garbage collector, the language and VM specifications do not say how GC should be implemented. In fact, there have been Java implementations (e.g., Epsilon, which you’ll meet later, and Lego Mindstorms) that didn’t implement any kind of GC at all!¹

Within the Oracle/OpenJDK environment, the GC subsystem is treated as a pluggable subsystem. This means that the same Java program can execute with different garbage collectors without changing the semantics of ...