What’s New in Java 17 GC? Key Changes to G1 and Parallel Collectors
This article reviews the most important JDK 17 updates to HotSpot’s G1 and Parallel garbage collectors, covering new large‑page support, dynamic reference processing, preventive collection, memory‑saving tweaks, and upcoming JDK 18 enhancements that impact performance and pause times.
Introduction
JDK 17 GA has been released, making it timely to summarize the most significant changes to the HotSpot G1 and Parallel GC collectors in this version.
Before diving into the details, note that there are no new JEPs for the GC sub‑components, and the full list of 312 HotSpot GC changes is available elsewhere.
Briefly on ZGC: this release dynamically adjusts concurrent GC threads to match the application, improving throughput while avoiding allocation stalls (JDK‑8268372), and significantly reduces marking stack memory usage (JDK‑8260267).
General Improvements
Since JDK‑8256155 the VM can reserve different large‑page sizes for different memory regions, allowing the code cache to use a different large‑page size than the Java heap and other reservations, which improves large‑page utilization.
Parallel GC
Parallel GC pause times have been reduced by executing more of the previously serial phases in parallel.
JDK‑8204686 implements dynamic parallel reference processing similar to G1. The implementation works as follows:
Based on
java.lang.ref.Reference, the VM determines the number of instances of each reference type (soft, weak, final, phantom) that need processing during GC. Parallel GC now launches a variable number of threads for the reference‑processing stage. Roughly, the implementation divides the observed count of references (via
j.l.ref.References) by
ReferencesPerThread(default
1000) to decide how many threads to use.
The flag
ParallelRefProcEnabledis now enabled by default, mirroring the feature introduced in G1 on JDK 11.
All internal weak‑reference handling now automatically leverages the parallelism introduced in JDK‑8268443.
JDK‑8248314 reduces Full GC pause by a few milliseconds.
Compared with JDK 16, some applications see a modest single‑digit percent throughput improvement, though much of this gain may stem from compiler enhancements rather than GC changes.
G1 GC
G1 now supports preventive garbage collection (JDK‑8257774). Microsoft contributed a special young‑collection that triggers before a potential evacuation failure, avoiding long pauses caused by insufficient space for object copying. The preventive collection is logged as
G1 Preventive Collectionand can be enabled with
G1UsePreventiveGC. It can be disabled via a diagnostic flag if it causes regressions.
A major Windows large‑page handling bug has been fixed (JDK‑8266489), allowing G1 to use large pages for regions larger than 2 MB, which can noticeably improve performance on large heaps.
JDK‑8262068 adds support for
MarkSweepDeadRatio, controlling how much waste is tolerated in regions scheduled for compaction. Regions with live occupancy above the default 95 % are not compacted. Setting the flag to
100disables the feature.
Early collection set trimming (JDK‑8262185) can significantly save memory by remembering only the set of old‑generation regions that are almost certainly going to be evacuated.
Additional parallelization of certain GC phases (e.g., JDK‑8214237) may further improve overall performance, as reported in "How fast is Java 17".
Other Notable Changes
Several JDK 17 changes are important but rarely affect end users directly.
The G1 collector code is being actively refactored: classes are being extracted from the monolithic
G1CollectedHeapto improve maintainability and pave the way for future work.
What’s Next
The GC team and contributors are already working on JDK 18. Notable upcoming changes include:
JDK‑8017163 dramatically reduces G1 memory consumption (about 75 % less) by rewriting the remembered set data structures. An NMT report image illustrates the memory usage differences between JDK 16, 17, and early 18 builds.
String deduplication support for Serial, Parallel, and ZGC (as in G1 and Shenandoah) via JEP 192.
Support for archived heap objects in Serial GC (JDK‑8273508).
Ongoing work by Hamlin Li on improving evacuation failure handling, with plans to introduce region locking in G1.
Translator’s Note
We have published several Java 17 articles and have more in the pipeline.
Upgrade to Java 17 – details you should know.
OpenJDK 17 Shenandoah – sub‑millisecond GC pauses (translation).
Follow the Java Architecture Diary to stay on track with technology learning!
Java Architecture Diary
Committed to sharing original, high‑quality technical articles; no fluff or promotional content.
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.