ZGC và Shenandoah — read barrier và concurrent compaction

TL;DR: Khác biệt cốt lõi giữa G1 và ZGC/Shenandoah là loại barrier. G1 dùng write barrier (tốn khi ghi, free khi đọc) — đủ cho SATB/RSet nhưng không compact concurrent được: app đọc reference cũ sau khi GC dời object thì thấy stale data, nên G1 phải STW lúc compact. ZGC/Shenandoah dùng read barrier (tốn khi đọc, ~10-15% throughput): mọi load đi qua barrier, redirect pointer tới object đã dời, nhờ đó compaction concurrent với app — pause dưới 10ms bất kể cỡ heap. ZGC hiện thực bằng colored pointer + load barrier; Shenandoah bằng load-reference barrier (từng dùng Brooks pointer, bỏ từ JDK 13). Generational ZGC: opt-in JDK 21 (JEP 439), default JDK 23 (JEP 474), non-gen gỡ ở JDK 24 (JEP 490).

Bài 12 kết ở Full GC 847ms của G1 — pause STW dài vì G1 phải dừng app khi compact toàn heap. Nếu SLA đòi p99 dưới 10ms, không flag G1 nào cứu được: bản chất G1 compact trong STW. Câu hỏi: collector nào compact mà không cần dừng app, và nhờ cơ chế gì?

Câu trả lời nằm ở một lựa chọn thiết kế: read barrier thay vì write barrier. Bài này mổ chính trục đó — vì sao read barrier (ZGC/Shenandoah) cho phép concurrent compaction mà write barrier (G1) không — rồi soi cách ZGC và Shenandoah hiện thực read barrier theo hai lối khác nhau (colored pointer vs load-reference barrier).

1. Write barrier vs read barrier — trục quyết định

Một hình dung trước khi vào cơ chế: coi GC như bưu điện xử lý khi object "chuyển nhà" (bị dời sang địa chỉ mới). Write barrier giống dán nhãn địa chỉ mới ngay lúc gửi — nhận thư (đọc) thì nhanh, nhưng ai cầm phong bì ghi địa chỉ cũ thì thất lạc. Read barrier giống tra sổ chuyển tiếp ngay lúc giao — mỗi lần giao (đọc) tốn công tra sổ, nhưng thư luôn tới đúng nhà mới dù địa chỉ trên phong bì đã cũ.

Bài 12 đã gặp write barrier của G1: mỗi lần app ghi reference field, barrier chạy (đẩy SATB queue, đánh dirty card). Đọc reference thì free. Đây là lựa chọn hợp lý cho G1 vì mục tiêu của nó là track mutation.

Nhưng write barrier có một giới hạn cứng khi muốn compact concurrent:

Vấn đề: nếu GC đã copy X sang địa chỉ mới nhưng app đọc reference cũ (không qua barrier vì write barrier chỉ chặn lúc ghi), app sẽ thấy địa chỉ cũ — stale data. Không có điểm chặn nào ở lúc đọc để redirect. Vì thế G1 buộc phải stop-the-world trong lúc compact: dừng mọi app thread, dời object, sửa hết pointer, rồi cho chạy lại.

Read barrier đảo ngược: tốn khi đọc reference, ít tốn khi ghi. Mỗi lần app load một reference từ heap, barrier chạy: kiểm tra reference có trỏ tới object đã dời không; nếu có → tra bảng forwarding, trả địa chỉ mới, app tiếp tục với pointer đúng mà không biết fixup vừa xảy ra. Nhờ đó GC dời object concurrent với app — không cần STW để compact.

2. ZGC — colored pointer và load barrier

ZGC (production Java 15, JEP 377) hiện thực read barrier bằng colored pointer: nhúng metadata vào chính bit của pointer 64-bit.

Trong scheme non-generational cổ điển (JDK 11-20): pointer dùng 42 bit thấp làm địa chỉ (4TB không gian đánh địa chỉ), 4 bit metadata — finalizable, remapped, marked1, marked0 — và phần bit cao bỏ trống. ZGC multi-map cùng một trang vật lý vào nhiều địa chỉ ảo ứng với các màu (nên phải dự trữ dải địa chỉ lớn; trần heap 4TB của scheme 42-bit này nâng lên 16TB từ JDK 13 khi trường offset mở rộng).

Colored pointer ZGC non-generational (Linux x86-64):
[ bit cao: bo trong ][ 4 bit metadata: F R M1 M0 ][ 42 bit dia chi ]

Bốn bit trên mã hoá trạng thái GC của object (đã mark, đã relocate + remap, finalizable). Ở mỗi phase, một tổ hợp bit là "màu tốt" (good color); load barrier chỉ cần kiểm pointer có màu tốt không, nếu không thì rẽ vào slow path fixup.

; x86 pseudo-assembly - ZGC load barrier
mov rax, [rbx + offset]     ; load reference
test rax, [bad_mask]        ; pointer co "mau xau" (can fixup)?
jnz slow_path               ; co -> tra forwarding table, cap nhat
; fast path: mau tot, dung tiep

Phase của ZGC — gần như concurrent hoàn toàn

flowchart TD
    A["Pause: Mark Start (~1ms): scan GC root"] --> B["Concurrent Mark: traverse heap, mark live"]
    B --> C["Pause: Mark End (~1ms): finalize mark"]
    C --> D["Pause: Relocate Start (~1ms): chot relocation set"]
    D --> E["Concurrent Relocate: copy object, ghi forwarding table"]
    E --> F["Ket thuc cycle (remap phan con lai gop vao Mark cycle sau)"]
    style A fill:#FCD34D
    style C fill:#FCD34D
    style D fill:#FCD34D
    style B fill:#6EE7B7
    style E fill:#6EE7B7

Ba pause ngắn (Mark Start, Mark End, Relocate Start — mỗi cái ~1ms, chỉ set cờ và chốt tập việc); mọi việc nặng (traverse heap, copy object, sửa pointer) đều concurrent. Pointer cũ được load barrier sửa lazy khi app đọc; phần còn sót được remap gộp vào pha Mark của chu kỳ kế tiếp, chứ không phải một phase quét riêng cuối cycle này.

3. Shenandoah — từ Brooks pointer tới load-reference barrier

Shenandoah (Red Hat, JEP 189, OpenJDK Java 12; production JEP 379 Java 15) cũng nhắm pause dưới 10ms bằng read barrier, nhưng cách hiện thực khác ZGC.

Brooks pointer (Shenandoah 1.0 — nay là lịch sử): phiên bản đầu thêm một forwarding word 8 byte vào mỗi object, bình thường trỏ về chính object; khi GC relocate, forwarding word của bản cũ trỏ tới địa chỉ mới. Mọi lần đọc đi qua forwarding word nên luôn nhận data đúng. Giá phải trả: một dereference thừa mỗi lần đọc và 8 byte/object (heap overhead ~5-15%).

Shenandoah 2.0 (JDK 13+): bỏ Brooks pointer, chuyển sang load-reference barrier (LRB) — barrier chỉ chèn khi load reference từ heap (chủ yếu hoạt động lúc evacuation, tức lúc GC copy object sống ra region mới), và forwarding ghi vào mark word (word tiêu đề sẵn có trong header mỗi object — xem bài 09) của bản cũ thay vì word riêng (không tốn 8 byte/object nữa). Kết quả: heap overhead giảm mạnh, throughput cải thiện rõ.

Ưu điểm Shenandoah còn giữ so với ZGC: không phụ thuộc bit của pointer, nên chạy được cả khi kiến trúc/OS chiếm hết dải địa chỉ pointer.

4. Câu chuyện generational — ZGC và Shenandoah qua các JDK

ZGC và Shenandoah đời đầu không generational: mọi object cùng một space, không tận dụng generational hypothesis (bài 06) nên quét toàn bộ mỗi cycle và throughput thấp hơn G1 đáng kể. Generational ZGC thêm young/old generation, thu hẹp gap throughput mà vẫn giữ pause dưới 10ms. Dòng thời gian:

• JDK 21 (JEP 439) — generational opt-in: phải bật -XX:+UseZGC -XX:+ZGenerational; non-generational vẫn mặc định.
• JDK 23 (JEP 474) — generational thành mặc định; non-generational bị deprecate.
• JDK 24 (JEP 490) — gỡ hẳn non-generational: obsolete cờ ZGenerational.

Generational Shenandoah đi sau: JEP 404 từng bị rút khỏi JDK 21, ship lại experimental ở JDK 24 (-XX:ShenandoahGCMode=generational); JEP 521 (JDK 25) bỏ nhãn experimental nhưng chưa làm nó mặc định.

5. Khi nào chọn ZGC, khi nào Shenandoah?

Đáp án: Shenandoah — nó dùng forwarding trong mark word (không đụng bit pointer) nên độc lập với dải địa chỉ; ZGC phụ thuộc bit trống trong pointer nên nền tảng này loại nó. Còn lại, trên OpenJDK upstream với heap lớn, ZGC (generational từ JDK 21) thường là mặc định hợp lý.

6. Pitfall tổng hợp

❌ Nhầm 1: Switch sang ZGC mà không bù throughput.

# G1, 10 server: 100k RPS -> ZGC cung 10 server: ~85k RPS (giam ~15%, thieu ~2 server)
java -XX:+UseZGC -Xmx24g MyApp

✅ Đo throughput trước/sau; cấp thêm ~15% CPU/instance để bù read-barrier overhead.

❌ Nhầm 2: Dùng ZGC cho heap nhỏ "cho pause thấp". ✅ Overhead ~10-15% không bù được với heap dưới 2GB — dùng G1 hoặc Serial (xem bài 06b).

7. 📚 Deep Dive Oracle

8. Liên hệ các bài khác

• G1 sâu — SATB, remembered set — write barrier của G1 và vì sao nó phải STW khi compact (đối lập trực tiếp với bài này).
• Chọn collector theo SLA và đọc GC log — khi nào SLA ép chọn ZGC/Shenandoah thay vì G1.
• GC — reachability và ba thuật toán nền — generational hypothesis mà generational ZGC/Shenandoah khai thác.
• Safepoint và stop-the-world — vì sao ngay cả ZGC vẫn có hai pause ngắn (cần safepoint để scan root).

9. Tóm tắt

• Khác biệt cốt lõi G1 vs ZGC/Shenandoah là loại barrier. Write barrier (G1) tốn khi ghi, free khi đọc — không chặn được app đọc pointer cũ khi GC dời object → phải STW compact. Read barrier (ZGC/Shenandoah) tốn khi đọc (~10-15% throughput), redirect pointer tới object đã dời → compaction concurrent, pause dưới 10ms mọi cỡ heap.
• ZGC: colored pointer (metadata trong bit pointer; scheme non-gen cổ điển 42 bit địa chỉ + 4 bit metadata) + load barrier. Generational ZGC (JDK 21+) thiết kế lại pointer.
• Shenandoah: load-reference barrier; Brooks pointer (8 byte/object) là đời đầu, bỏ từ JDK 13 (forwarding vào mark word). Không phụ thuộc bit pointer → chạy được nơi ZGC không.
• Generational ZGC: opt-in JDK 21 (JEP 439), default JDK 23 (JEP 474), non-gen gỡ JDK 24 (JEP 490). Generational Shenandoah: experimental JDK 24 (JEP 404), non-experimental JDK 25 (JEP 521), chưa default.
• ZGC/Shenandoah không miễn phí: đổi throughput lấy latency — chỉ chọn khi latency là ràng buộc thật, và cấp thêm máy để bù.

10. Tự kiểm tra

Bài tiếp theo: Mini-challenge: Debug memory leak với heap dump và JFR