Backend Development 10 min read

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.

Java Architecture Diary
Java Architecture Diary
Java Architecture Diary
What’s New in Java 17 GC? Key Changes to G1 and Parallel Collectors

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

ParallelRefProcEnabled

is 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 Collection

and 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

100

disables 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

G1CollectedHeap

to 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!

JavaperformanceGarbage CollectionJDK 17G1Parallel GC
Java Architecture Diary
Written by

Java Architecture Diary

Committed to sharing original, high‑quality technical articles; no fluff or promotional content.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.