Why G1GC? Understanding Soft Real‑Time and Pause‑Time Prediction in Java

Why Choose G1?

In high‑frequency e‑commerce systems like Daily Fresh, low latency and high availability are critical; a stop‑the‑world (STW) pause can dramatically affect response times and conversion rates. G1GC is introduced to provide soft real‑time guarantees while keeping throughput high.

Soft Real‑Time

Soft real‑time means the system may exceed a deadline a few times as long as the overruns stay within user‑tolerable limits, unlike hard real‑time systems that must guarantee strict timing.

G1 achieves this by allowing users to specify a target pause time and by predicting the next GC pause; if the prediction exceeds the target, G1 splits the GC work or delays it.

G1GC Principles

Origin

G1 was introduced in Java 6, supported from Java 7, and became the default collector in Java 9, replacing CMS.

G1 Heap Structure

The heap is divided into equal‑sized regions , each defaulting to 1 MB. Objects are allocated into these regions, and empty regions remain free.

MIN_REGION_SIZE = 1MB

MAX_REGION_SIZE = 32MB

TARGET_REGION_NUMBER = 2048

The region size is calculated from the minimum heap size (-Xms) divided by the target number of regions, then rounded up to the nearest power of two, bounded between the minimum and maximum sizes.

Concurrent Marking

Initial Mark

During the initial mark, G1 creates two bitmaps for each region (NextBitmap and PrevBitmap) and marks objects reachable directly from GC roots.

SATB (Snapshot‑At‑The‑Beginning)

When concurrent marking starts, a snapshot of object references is taken. Mutator threads maintain local SATB queues that record reference changes; the GC thread periodically scans these queues to keep the marking accurate.

Final Mark

After concurrent marking, any remaining SATB local queues are scanned to ensure all live objects are marked.

Live Object Counting

The number of live bytes in each region’s NextBitmap is summed into next_marked_bytes, which later helps compute transfer efficiency.

Cleanup

GC threads move the top pointer to the region bottom, reset counters, and swap bitmaps, preparing for the next cycle.

Object Transfer

Live objects are moved to free regions, and the original regions are cleared. Transfer efficiency is used to rank regions for reclamation.

Remembered Set

Inter‑region references are tracked using a card table (one 1 B card per 512 B of heap). Each region maintains a remembered set (implemented as a hash table) that records which cards reference objects in other regions.

When an object’s field is updated, a write barrier records the dirty card in the thread’s remembered‑set log; once the log is full, it is flushed to a global log for a dedicated maintenance thread to update the remembered sets.

Pause‑Time Prediction

G1 predicts pause times using a decaying variance algorithm based on historical pause data. The predicted time equals a fixed transfer cost plus the sum of per‑region costs and the cost of scanning remaining dirty cards.

Conclusion

Relying solely on low‑level JVM tuning is insufficient; developers should write clean, maintainable code while using G1GC to meet performance goals.