Understanding the G1 (Garbage‑First) Garbage Collector in Java

Garbage‑First (G1) is the most advanced collector in the HotSpot VM roadmap, introduced as an early‑access feature in JDK 6u14 and slated for a production‑ready version in a later JDK 7 update.

Features of the G1 Collector

G1 is a server‑side garbage collector intended to eventually replace the CMS collector. Its main advantages are:

Parallelism and concurrency: G1 exploits multiple CPUs/cores to shorten stop‑the‑world pauses, allowing many GC activities to run concurrently with application threads.

Generational collection: Like other collectors, G1 retains the generational concept, but it can manage the whole heap independently while still treating young and old objects differently for better efficiency.

Space integration: Implemented as a global "mark‑compact" algorithm and locally as a "copy" algorithm, G1 avoids fragmentation, providing contiguous free memory even after long‑running applications allocate large objects.

Predictable pauses: G1 lets users specify a maximum GC time (N ms) within a time slice of M ms, effectively offering a real‑time Java (RTSJ) pause‑time model.

Implementation Idea

Unlike previous collectors that scan the entire young or old generation, G1 divides the heap into equal‑sized regions. Both young and old generations are represented as collections of regions rather than physically separate spaces.

G1 tracks the amount of reclaimed space and the time required for each region, maintains a priority list, and during a GC cycle it selects the regions with the highest "garbage‑first" value that fit within the user‑specified pause budget.

The region‑based approach introduces complexity: objects in one region may be referenced from any other region, so a full‑heap scan would be required for reachability analysis. G1 solves this with per‑region Remembered Sets (RSets) that record cross‑region references via write barriers and CardTables, allowing GC to avoid scanning the entire heap.

Operation Process

Ignoring the overhead of maintaining RSets, G1’s work can be divided into four steps:

Initial Marking

Concurrent Marking

Final Marking

Live Data Counting and Evacuation (selection and reclamation)

The first three phases are similar to CMS, with the initial mark being a short stop‑the‑world pause, the concurrent mark running in parallel with the application, and the final mark fixing any changes that occurred during the concurrent phase. The last phase sorts regions by reclamation value and schedules collection so that the pause time stays within the user‑defined budget.

Figure 1. G1 Collector execution diagram

Actual Performance of G1

Because a mature production version of G1 is still lacking, public performance data are scarce. The article cites Sun’s own benchmark (SPECjbb and telco workloads on a Sun V880 server) and a discussion from StackOverflow.

Soft‑real‑time goal compliance statistics (V % = failure probability, avgV % = average over‑run percentage, wV % = worst‑case over‑run) show that G1 generally meets the pause targets better than CMS, especially at larger heap sizes, though occasional worst‑case pauses of 100 % GC time were observed.

Benchmark / configuration

Soft real‑time goal compliance statistics by Heap Size

V%

avgV%

wV%

V%

avgV%

wV%

V%

avgV%

wV%

Table rows omitted for brevity; they contain the original numeric data translated into English column headings

The throughput tests (average of three SPECjbb runs and fifteen telco runs) indicate that G1’s throughput is roughly proportional to the allowed maximum GC time. Compared with CMS, CMS has a 5‑10 % advantage on SPECjbb for heap sizes above 768 MB, and a 3‑4 % advantage on telco workloads.

Figure 2. Throughput test results

A real‑world anecdote from StackOverflow describes a large‑scale application (60‑70 GB heap, 20‑50 GB live data) on Linux JDK 6u22 where G1 provided much more predictable pauses than Parallel Scavenge, though CMS remained the author’s current choice. The author concludes that no collector is universally best; the optimal choice depends on hardware, workload, configuration, and tuning goals, and should be validated with your own tests.

References

Sun Lab paper “ Garbage‑First Garbage Collection ” by David Detlefs, Christine Flood, Steve Heller, Tony Printezis

The Garbage‑First Garbage Collector

G1: Java's Garbage First Garbage Collector