GC Modern Deep — G1, ZGC, Shenandoah: cơ chế, tradeoff và khi nào chọn

TL;DR: Bài 05 cho thấy G1 là default Java 9+ và ZGC đạt pause dưới 10ms. Bài này đào sâu cơ chế: G1 dùng region-based heap + SATB (Snapshot-At-The-Beginning) concurrent marking + Remembered Set để track inter-region reference. ZGC dùng colored pointer (3 bit màu trong 64-bit pointer) + load barrier (check màu khi đọc reference) để relocate object hoàn toàn concurrent. Shenandoah (RedHat) dùng Brooks pointer (indirection layer) + read barrier để compact concurrent. Write barrier (G1) — tốn khi ghi, free khi đọc. Read barrier (ZGC, Shenandoah) — tốn khi đọc nhưng cho phép concurrent compaction. Overhead thực tế: ZGC/Shenandoah 10-20% throughput thấp hơn G1. Chọn dựa trên SLA latency và heap size.

Bài 05 nói về GC overview ở mức "vì sao chia young/old, cách đọc GC log, khi nào chọn Parallel vs G1 vs ZGC". Bài này là deep dive: cơ chế kỹ thuật bên trong từng collector, lý do design khác nhau, và tradeoff chi tiết. Mục tiêu: có đủ nền tảng để đọc GC tuning guide, hiểu GC log chi tiết, và lý luận về GC selection thay vì chỉ copy-paste recommendation.

1. Scenario — SLA 99.9% latency vượt ngưỡng do Full GC đêm

Service recommendation API, SLA 99.9% latency dưới 100ms. Heap 24GB, dùng G1 default. Mỗi đêm khoảng 2h sáng:

[02:14:33][gc] GC(187) Pause Full (Ergonomics) 24576M->18432M(24576M) 847.234ms

Full GC 847ms gây breach. 99.9% latency trong 1 giờ = 3.6 giây budget, 847ms GC xài hết 23% budget trong 1 lần. Cần giảm max pause xuống dưới 10ms. Lựa chọn?

Câu trả lời không đơn giản là "switch sang ZGC". Cần hiểu tại sao Full GC xảy ra với G1, ZGC fix bằng cơ chế gì, và trade-off sẽ là gì sau khi switch. Bài này trang bị đủ để trả lời.

2. Region-based GC — nền tảng chung

Region-based GC là paradigm phổ biến trong cả 3 collector: G1, ZGC, Shenandoah. Thay vì chia heap thành 2 half (young/old cứng nhắc), heap được chia thành nhiều region nhỏ.

Tại sao region-based tốt hơn fixed generation:

• Partial collection: GC có thể chọn collect 1 subset region (những region có nhiều rác nhất — "garbage first") thay vì phải scan toàn heap. Giảm thời gian mỗi GC cycle.
• Flexible assignment: region có thể đổi role (Eden → Survivor → Old → Free) tuỳ nhu cầu. Không bị cứng nhắc "old phải chiếm 70%".
• Concurrent work: GC thread có thể làm việc trên 1 region trong khi app thread dùng region khác.
• Heap fragmentation: compact từng region nhỏ dễ hơn compact toàn heap.

3. G1 GC — cơ chế SATB và Remembered Set

G1 (Garbage-First), default Java 9+, dùng 3 structure kỹ thuật quan trọng:

SATB — Snapshot-At-The-Beginning

SATB là thuật toán concurrent marking: trước khi bắt đầu marking phase, JVM chụp snapshot trạng thái reference graph. Mọi object live tại thời điểm snapshot sẽ được coi là live trong GC cycle này, ngay cả khi app thread xoá reference sau đó.

Tại sao cần SATB: nếu GC thread đang mark object A, app thread đồng thời xoá reference A→B và thêm reference C→B, GC thread có thể bỏ sót B (chưa scan C). SATB đảm bảo: nếu B live lúc bắt đầu marking, B được mark live — kể cả khi reference đến B thay đổi trong quá trình mark.

Write barrier của G1 (SATB write barrier): mỗi khi app thread ghi vào reference field, barrier ghi giá trị cũ của field vào SATB queue. GC thread đọc queue và mark các object cũ là live. Chi phí: mỗi reference write thêm 1 buffer write (~5-10 ns, amortized).

App thread: field.ref = newObject   // write
SATB barrier: satb_queue.push(field.ref.old)  // ghi gia tri cu vao queue
GC thread: process satb_queue -> mark old objects live

Remembered Set (RSet)

Remembered Set là cấu trúc per-region ghi lại các reference từ region khác vào region đó. Khi GC collect region R, GC cần biết region nào ngoài R có pointer vào R — để update sau khi compact. Thay vì scan toàn heap (tốn O(heap)), GC scan RSet (tốn O(RSet size)).

RSet được maintain bởi card table write barrier: mỗi khi reference field được ghi, JVM đánh dấu 1 card (512 byte chunk) trong card table. Refinement thread (chạy concurrent) đọc card table và update RSet.

Chi phí G1:

• Write barrier: ~5-10 ns mỗi reference write.
• Refinement thread: ~1 core liên tục.
• RSet overhead: ~5-10% extra memory.

G1 GC cycle

flowchart LR
    A[Young GC - STW\nEvacuate Eden + Survivor] --> B[Concurrent Marking\nSATB - app runs]
    B --> C[Remark - short STW\nDrain SATB queues]
    C --> D[Cleanup - short STW\nIdentify empty regions]
    D --> E[Mixed GC - STW\nYoung + high-garbage Old]
    E --> F{Old region\npressure?}
    F -- Low --> A
    F -- High -- Full GC trigger --> G[Full GC - long STW\nMark-compact entire heap]

Full GC trong G1 xảy ra khi Mixed GC không kịp dọn Old gen (allocation vượt evacuation speed). G1 fallback sang single-thread mark-compact toàn heap — đây là source của 847ms pause trong scenario đầu bài. Bài 09 giải thích tại sao TTSP còn cộng thêm vào nữa.

Chống Full GC G1:

# Giam threshold start concurrent marking som hon
-XX:InitiatingHeapOccupancyPercent=35   # default 45
# Tang so GC thread
-XX:ParallelGCThreads=8
-XX:ConcGCThreads=4
# Tang heap hoac giam allocation rate

4. ZGC — colored pointer và load barrier

ZGC (Z Garbage Collector), production Java 15+, Generational Java 21+ (JEP 439). Mục tiêu: pause dưới 10ms với mọi heap size, từ vài GB đến 16TB.

Cơ chế cốt lõi của ZGC khác biệt hoàn toàn với G1: thay vì dùng write barrier để track mutation, ZGC dùng read barrier để detect và fix stale pointer khi đọc reference.

Colored pointer — 3 bit màu trong pointer

ZGC nhúng metadata vào pointer 64-bit bằng cách sử dụng các bit cao (không dùng bởi OS do địa chỉ thực tế dùng 44-48 bit trên Linux x86-64):

64-bit reference trong ZGC (Linux x86-64):
Bit: [63...46][45][44][43][42][41...0]
         |      |   |   |   |    |
   unused(18) bad fin remap mark1 mark0  address(42)

bad      : pointer đang invalid (debugging)
finalizable: đã finalize
remapped : đã được relocate và pointer đã update
marked0/1: đã được mark live trong marking phase (alternating bit)

3 bit quan trọng nhất trong GC cycle: marked, remapped, finalizable. Giá trị của các bit này xác định trạng thái của object trong GC phase hiện tại.

Load barrier — check khi đọc reference

Mỗi khi app code đọc một reference từ heap (load object reference từ field của object khác), JIT chèn một load barrier nhỏ:

; x86 pseudo-assembly - ZGC load barrier
mov rax, [rbx + offset]     ; load reference normally
test rax, [bad_mask]        ; check "bad" bits (metadata)
jnz slow_path               ; if bits set -> need fixup
; fast path: reference is good, continue

Nếu metadata bits set (pointer cũ, cần update):

• Slow path: JVM xác định địa chỉ mới của object (từ forwarding table), update pointer, trả về pointer mới cho app thread. App thread tiếp tục với pointer đúng — không biết fixup xảy ra.

Load barrier overhead: ~5-10% throughput (mỗi reference load có thêm check). Đây là trade-off cốt lõi của ZGC.

ZGC phases — gần hoàn toàn concurrent

flowchart LR
    A["Pause: Mark Start ~1ms\n(scan GC roots, set mark bit)"] --> B
    B["Concurrent Mark\n(traverse heap, mark live objects)"] --> C
    C["Pause: Mark End ~1ms\n(drain mark queues, finalize)"] --> D
    D["Concurrent Reference Processing\n(weakRef, phantom, finalization)"] --> E
    E["Concurrent Relocation Set Selection\n(choose regions to compact)"] --> F
    F["Concurrent Relocation\n(copy live objects, update forwarding table)"] --> G
    G["Concurrent Remapping\n(update all pointers)"] --> H[End cycle]

Chỉ 2 pause: Mark Start (~1ms) và Mark End (~1ms). Tổng pause per cycle thường dưới 2ms. Mọi work thực (traverse heap, copy object, update pointer) đều concurrent với app.

Forwarding table: khi GC copy object từ địa chỉ cũ sang địa chỉ mới, GC lưu mapping old_addr → new_addr trong forwarding table. Load barrier tra cứu table này khi gặp pointer cũ (remapped bit = 0). Sau khi tất cả pointer được update (remapping phase), forwarding table được free.

Generational ZGC (Java 21, JEP 439)

ZGC trước Java 21 không có generational — không tận dụng generational hypothesis (phần lớn object chết trẻ). Tất cả object trong cùng 1 GC space.

Java 21 thêm generational ZGC: Young generation + Old generation, giống G1. Young GC thường xuyên hơn, cheap hơn. Old GC concurrent. Throughput cải thiện đáng kể so với non-generational ZGC, trong khi giữ pause dưới 10ms.

# Java 21+: generational ZGC mac dinh
java -XX:+UseZGC -Xmx16g MyApp

# Java 17-20: non-generational ZGC
java -XX:+UseZGC -Xmx16g MyApp

5. Shenandoah — Brooks pointer và concurrent compaction

Shenandoah (RedHat, JEP 189, OpenJDK Java 12+). Mục tiêu tương tự ZGC: pause dưới 10ms. Approach khác.

Brooks pointer — indirection per object

Shenandoah thêm 1 word (8 byte) vào mỗi object: Brooks pointer (tên theo nhà nghiên cứu Rodney A. Brooks). Brooks pointer bình thường trỏ đến chính object đó (self-pointer). Khi GC relocate object sang địa chỉ mới, Brooks pointer cũ được update để trỏ đến địa chỉ mới.

Before relocation:
Object A at addr 0x1000:
  [brooks_ptr → 0x1000][mark_word][klass_ptr][fields...]
  (self-pointer, no relocation)

After relocation (GC copies A to 0x5000):
Object A at addr 0x1000 (old):
  [brooks_ptr → 0x5000][mark_word][klass_ptr][fields...] <- forwarding
Object A at addr 0x5000 (new, canonical):
  [brooks_ptr → 0x5000][mark_word][klass_ptr][fields...] <- actual data

Mọi reference đọc đến object A đều đi qua Brooks pointer — dù đọc từ địa chỉ cũ (0x1000) hay mới (0x5000), đều nhận về data đúng tại 0x5000.

Read barrier: mỗi lần đọc reference, Shenandoah follow Brooks pointer. Chi phí: 1 extra pointer dereference per load. Tương tự ZGC overhead.

Ưu điểm Brooks pointer so với ZGC colored pointer:

• Không phụ thuộc bit cao của pointer — hoạt động trên kiến trúc 32-bit hoặc OS dùng hết 48 bit địa chỉ.
• Không cần thay đổi pointer encoding.

Nhược điểm: mỗi object tốn thêm 8 byte (Brooks pointer). Heap overhead ~5-15% tuỳ object size average.

Shenandoah "elimination optimization" (Java 13+): JIT nhận ra pattern self-pointer và có thể elide Brooks pointer dereference trong nhiều trường hợp — giảm overhead load barrier. Bài whitepaper gọi là "Brooks pointer elimination".

Generational Shenandoah (Java 21 preview)

Tương tự Generational ZGC, thêm young/old generation để giảm GC pressure. Experimental trong Java 21+, production-ready dự kiến Java 23-24.

6. Write barrier vs Read barrier — tradeoff cơ bản

Đây là phân chia quan trọng nhất giữa GC modern:

Write barrier (G1, CMS legacy):

• Tốn chi phí khi ghi reference field (obj.field = other).
• Đọc reference: free (không có overhead).
• Dùng để: track mutation (SATB), maintain Remembered Set (card table).
• Phù hợp với: workload đọc nhiều hơn ghi (read-heavy).

Read barrier (ZGC, Shenandoah):

• Tốn chi phí khi đọc reference field (x = obj.field).
• Ghi reference: chi phí thấp hơn (không cần full write barrier).
• Dùng để: detect stale pointer khi load, trigger fixup, cho phép concurrent relocation.
• Overhead cao hơn vì đọc reference xảy ra nhiều hơn ghi nhiều lần trong code thực tế.
• Nhưng: cho phép concurrent compaction mà write barrier không làm được.

Tại sao read barrier cần cho concurrent compaction:

Khi GC muốn copy object đang được app thread dùng, cần đảm bảo app thread luôn thấy data đúng. Write barrier không đủ — app thread đọc reference cũ (không qua barrier) vẫn thấy địa chỉ cũ. Read barrier đảm bảo mọi load đều qua barrier → có thể intercept và redirect sang địa chỉ mới. Compaction có thể xảy ra concurrent.

flowchart LR
    subgraph WriteBarrier[Write Barrier - G1]
        W1[App: obj.field = X] --> W2[Barrier: record old value]
        W3[App: y = obj.field] --> W4[No barrier - direct load]
        W4 --> W5[GC cannot move obj while app reads it]
    end

    subgraph ReadBarrier[Read Barrier - ZGC]
        R1[App: obj.field = X] --> R2[Minimal barrier]
        R3[App: y = obj.field] --> R4[Barrier: check color bits]
        R4 --> R5[If relocated: return new address]
        R5 --> R6[GC CAN move obj concurrently]
    end

7. So sánh 4 collector

8. Khi nào chọn GC nào

flowchart TD
    A[Bắt đầu] --> B{Workload type?}
    B -- Batch / offline / ETL --> C[Parallel GC]
    B -- Web / microservice --> D{SLA latency p99?}
    D -- Vượt 200ms OK --> E[G1 - default, it tune]
    D -- Dưới 100ms --> F{Heap size?}
    F -- Dưới 32 GB --> G[G1 well-tuned hoac ZGC]
    F -- Vượt 32 GB --> H[ZGC]
    D -- Dưới 10ms --> H
    H --> I{Java version?}
    I -- Java 21+ --> J[Generational ZGC - uu tien]
    I -- Java 17-20 --> K[ZGC non-gen hoac Shenandoah]

Parallel GC: batch job, ETL, scientific compute, offline analytics. Throughput tối đa, pause chấp nhận được (không có user request). -XX:+UseParallelGC.

G1 GC: web service, microservice, API server với heap 4-32 GB. Default Java 9+. Pause 50-200ms acceptable cho SLA 99th percentile 500ms. Không cần tune nhiều — default thường đủ tốt. -XX:+UseG1GC.

ZGC: latency-critical service (trading platform, real-time bidding, gaming backend), heap lớn (vượt 32 GB), SLA p99 dưới 10ms. Java 21+ dùng Generational ZGC cho throughput tốt hơn. -XX:+UseZGC.

Shenandoah: tương tự ZGC về latency target. Phù hợp nếu kiến trúc không support ZGC colored pointer (32-bit system, special OS), hoặc prefer RedHat support. -XX:+UseShenandoahGC.

9. Pitfall — các sai lầm phổ biến khi chọn và tune GC

Pitfall 1 — Switch sang ZGC mà không bù throughput overhead:

# Truoc: G1, 10 server x 16 vCPU, throughput 100k RPS
java -XX:+UseG1GC -Xmx24g MyApp

# Sau: ZGC, cung 10 server, throughput 85k RPS (giam 15%)
java -XX:+UseZGC -Xmx24g MyApp

# Dung: can them 2 server (12 server) hoac scale CPU de bu overhead

Switch sang ZGC mà không đánh giá throughput drop → capacity shortage → latency tăng ironically.

Pitfall 2 — G1 Full GC do allocation spike:

Pattern: alloc rate binh thuong 500 MB/s, spike len 2 GB/s (batch import)
G1 concurrent marking khong kip doc -> Old day -> Full GC

Fix:

-XX:InitiatingHeapOccupancyPercent=35  # Start marking som hon (default 45)
-XX:G1ReservePercent=15                # Giu 15% heap buffer (default 10)
-XX:ConcGCThreads=4                    # Tang GC thread (default cores/4)

Hoặc tách batch import ra process riêng với Parallel GC, không để batch spike ảnh hưởng online service.

Pitfall 3 — Humongous object trong G1:

G1 có region size (1-32 MB). Object lớn hơn 50% region size → Humongous region — cả region dành cho 1 object. Humongous region không được GC trong Young GC thông thường, chỉ được clean trong concurrent cycle. Nhiều Humongous object → Old gen pressure → Full GC sớm.

// Pitfall: buffer 50MB trong G1 voi region size 32MB
byte[] buffer = new byte[50 * 1024 * 1024];  // Humongous!
// Fix 1: dung DirectByteBuffer (off-heap)
ByteBuffer direct = ByteBuffer.allocateDirect(50 * 1024 * 1024);
// Fix 2: tang region size (giam so Humongous)
// -XX:G1HeapRegionSize=64m  (mac dinh 1-32 tuy heap size)

Pitfall 4 — ZGC và heap quá nhỏ:

ZGC overhead là overhead absolute — không scale tốt với heap nhỏ. Heap 512 MB với ZGC: overhead 10-20% = 50-100 MB lost. Với G1, overhead cũng tương tự nhưng GC cycle nhanh hơn vì heap nhỏ.

# Heap < 2 GB: G1 hoac Serial GC thích hợp hơn ZGC
java -XX:+UseSerialGC -Xmx512m SmallApp   # Single thread GC, it overhead
java -XX:+UseG1GC -Xmx2g MediumApp        # Balanced
java -XX:+UseZGC -Xmx16g LargeApp         # ZGC value xuất hiện rõ

10. Tuning thực chiến — các flag quan trọng nhất

G1 production tuning:

java \
  -XX:+UseG1GC \
  -Xms16g -Xmx16g \                          # Xms = Xmx cho server
  -XX:MaxGCPauseMillis=100 \                 # Soft pause target
  -XX:InitiatingHeapOccupancyPercent=35 \    # Start concurrent mark som
  -XX:G1HeapRegionSize=16m \                 # Region size (auto hoac manual)
  -XX:ConcGCThreads=4 \                      # Concurrent GC threads
  -XX:ParallelGCThreads=8 \                  # STW GC threads
  -Xlog:gc*=info:file=gc.log:time,uptime \   # GC logging mandatory
  MyApp

ZGC production tuning:

java \
  -XX:+UseZGC \
  -Xms16g -Xmx16g \
  -XX:ConcGCThreads=4 \           # Concurrent GC threads (default auto)
  -XX:SoftMaxHeapSize=14g \       # Soft heap limit (ZGC specific)
  -Xlog:gc*=info:file=gc.log \
  MyApp
# ZGC it can tune hon G1 - heuristic tu thich nghi tot hon

Logging bắt buộc cho production:

-Xlog:gc*=info:file=/var/log/app/gc-%t.log:time,uptime,level:filecount=5,filesize=20m
# filecount=5: giu 5 file
# filesize=20m: rotate khi dat 20 MB
# Gui vao log aggregator (Datadog, ELK) de alert

11. Deep Dive

12. Self-check

java -XX:+UseZGC -Xms40g -Xmx40g -XX:SoftMaxHeapSize=36g     # ZGC try to stay under 36g (buffer)
-XX:ConcGCThreads=6         # Concurrent GC, tune theo core count
-Xlog:gc*=info:file=/var/log/gc.log:time,uptime:filecount=5,filesize=20m -XX:+HeapDumpOnOutOfMemoryError MyApp