Fundamentals 16 min read

Understanding G1 Garbage Collector: Architecture, Mechanisms, and GC Log Analysis

This article provides a comprehensive overview of the G1 (Garbage First) collector, covering its region-based memory layout, cross‑generation reference handling, SATB write barriers, various GC phases (Young, Mixed, Full), and how to interpret detailed G1 GC logs for performance tuning.

Big Data Technology & Architecture
Big Data Technology & Architecture
Big Data Technology & Architecture
Understanding G1 Garbage Collector: Architecture, Mechanisms, and GC Log Analysis

Why Learn G1

G1 (Garbage First Collector) is the latest JVM garbage collector that addresses CMS's concurrent mode failures, reduces pause times for large heaps, performs memory compaction during collection, and has become the default collector in Java 9, making it essential knowledge for Java developers.

G1 GC Principles

Region

G1 divides the heap into equal‑sized Regions (default 512 KB). Each Region is logically contiguous but may be physically scattered. Regions are classified as E (Eden), S (Survivor), O (Old), and H (Humongous), with E and S belonging to the young generation and O and H to the old generation.

Humongous regions hold objects larger than half a Region size, are allocated in the old generation, and trigger a GC when they cannot fit.

Cross‑Generation References

To avoid scanning the entire old generation during Young GC, G1 uses Card Table and Remembered Set (RSet) structures, which record references from old to young regions, while young‑to‑old references are not tracked.

RSet: remembers all external references to a Region.

Card: a fixed‑size unit analogous to a memory page, used to track dirty cards.

The relationship between RSet and Card is illustrated by mapping each Region to a hash table where each Card entry indicates whether it contains references to other Cards.

SATB (Snapshot At The Beginning)

SATB captures a snapshot of live objects at the start of concurrent marking, ensuring correctness of the three‑color marking algorithm. G1 employs a pre‑write barrier that records reference changes into satb_mark_queue, which is processed during the remark phase to maintain snapshot integrity.

Newly allocated objects after the start of marking are identified using two pointers, prevTAMS and nextTAMS, within each Region.

G1 GC Modes

Young GC

Collects all young Regions. When Eden is full, objects are promoted to Survivor or directly to Old if Survivor is insufficient. The evacuation pause moves live objects to empty Regions.

Mixed GC

Collects young Regions plus a selected subset of old Regions based on the pause‑time target (default 200 ms). The selection is driven by the -XX:MaxGCPauseMillis parameter and the pause prediction model.

Mixed GC consists of:

Initial Mark (STW) – marks roots reachable from GC roots.

Concurrent Marking – runs in parallel with application threads, updating RSet and scanning dirty cards.

Remark – final STW phase to capture changes.

Cleanup – frees empty Regions.

Evacuation – copies live objects from selected Regions (CSet) to empty Regions.

Full GC

If G1 cannot keep up (e.g., insufficient to‑space during evacuation or heap exhaustion before concurrent marking finishes), it falls back to a Serial Full GC, which incurs a long STW pause and should be avoided.

Log Analysis

Using -XX:+PrintGCDetails and related flags, the article explains how to read G1 GC logs, covering timestamps, pause times, parallel task details, RSet updates, card table processing, and heap size changes for Young, Mixed, and Full GC events.

Additional flags such as -XX:+PrintAdaptiveSizePolicy and -XX:+PrintTenuringDistribution provide insights into collector ergonomics and Survivor age distribution, aiding performance tuning.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

JavaJVMMemory ManagementGarbage Collectionperformance tuningg1-gc
Big Data Technology & Architecture
Written by

Big Data Technology & Architecture

Wang Zhiwu, a big data expert, dedicated to sharing big data technology.

0 followers
Reader feedback

How this landed with the community

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.