Java GC Evolution: From JDK 8 to JDK 18 and Performance Gains
Since JDK 8, HotSpot’s garbage collectors have undergone extensive refinements—introducing G1 as default, adding ZGC and Shenandoah, and optimizing Parallel GC—resulting in notable gains in throughput, reduced pause latency, and lower auxiliary memory usage, as demonstrated by SPECjbb2015 benchmarks across JDK 8 to JDK 18.
Java Garbage Collection Evolution: From JDK 8 to JDK 18
In March 2014 JDK 8 was released, and since then ten JDK versions have appeared, culminating in JDK 18. This article reviews the full development of HotSpot JVM garbage collectors.
About Garbage Collection, Metrics and Trade‑offs
The component that manages the application heap in HotSpot JVM is called the Garbage Collector (GC). Its basic responsibilities are:
Provide memory quickly when the application requests allocation.
Detect and reclaim unused memory ("garbage") efficiently.
Return reclaimed memory to the application as fast as possible.
GC algorithms are evaluated by three performance metrics:
Throughput : amount of work completed per unit time.
Latency : pause time caused by GC.
Memory overhead : extra memory required beyond the application heap.
These metrics are interrelated; improving one often degrades another, forming a performance‑trade‑off triangle.
OpenJDK GC in JDK 18
OpenJDK provides five main collectors, each focusing on different metrics:
Parallel GC : throughput‑oriented, minimal pause consideration.
G1 GC : balances throughput and latency, uses concurrent phases to reduce pause times.
ZGC and Shenandoah GC : prioritize low latency, non‑generational, introduced experimentally in JDK 12 and JDK 15.
Serial GC : small memory footprint and fast startup, suitable for small or short‑lived applications.
G1 GC Overview
G1 became the default collector from JDK 9 onward. It uses generational collection, dividing the heap into a young generation (small, fast to collect) and an old generation (larger, collected incrementally). G1 tracks live objects in parallel with the application, reducing pause times while slightly lowering throughput.
Progress from JDK 8 to JDK 18
Using the SPECjbb2015 benchmark on a 16 GB heap, the following improvements were observed:
Throughput (maxjOPS) increased ~5 % from JDK 8 to JDK 11 and ~18 % from JDK 8 to JDK 18 for G1.
Average pause latency dropped from 124 ms (JDK 8) to 89 ms (JDK 18); the 99th‑percentile fell from 176 ms to 104 ms.
Setting a stricter pause target (50 ms) allowed G1 to meet the goal without increasing total pause time.
Parallel GC also showed modest throughput gains (≈2‑10 %).
Memory overhead for G1 fell dramatically: native memory usage dropped from ~5.8 GB (JDK 8) to ~1.25 GB (JDK 18), about 6 % of heap size.
Future of Garbage Collection
Upcoming work includes solving native‑code reference stalls (JEP 423), reducing G1’s impact on overall throughput, further shrinking G1’s auxiliary bitmap, and making ZGC/Shenandoah generational.
Conclusion
The HotSpot JVM garbage collectors have made substantial progress from JDK 8 to JDK 18 across all three key metrics—throughput, latency, and memory overhead. Each new JDK release brings visible improvements, and the trend is expected to continue.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.