Compressed OOP và 32GB cliff — cái bẫy khi chọn heap size

TL;DR: Compressed OOP biểu diễn mỗi reference (và klass pointer) bằng 32 bit thay vì 64 bit, cắt một nửa kích thước con trỏ và tiết kiệm khoảng 20-40% heap cho object nhiều reference. Nó lợi dụng việc mọi object align 8 byte (3 bit thấp của địa chỉ luôn bằng 0) để bỏ 3 bit đó khi lưu, khôi phục khi dùng. Chính độ rộng con trỏ 32 bit cộng alignment 8 byte chốt trần compressed OOP ở 32 GB. Đặt heap chạm 32 GB, JVM tự tắt nó — mọi reference phình lên 8 byte, object to ra 30-50%. Nghịch lý 32GB cliff: heap 31 GB compressed thường chứa nhiều object hơn heap 33 GB uncompressed.

Một team thấy app hay Full GC nên nâng heap từ 30 GB lên 40 GB cho "thoáng". Kết quả ngược: GC còn dày hơn, và app OOM sớm hơn trước. Không rò rỉ mới, không đổi code — chỉ đổi một cờ -Xmx. Thủ phạm là một ngưỡng ẩn ngay dưới chân họ: khi heap vượt 32 GB, JVM âm thầm tắt compressed OOP và mọi object phình to.

Bài 09 đã cho thấy klass pointer chỉ 4 byte "khi compressed class pointer bật". Bài này mổ cơ chế nén đó, phép toán chốt con số 32 GB, và vì sao chọn heap size quanh ngưỡng này là một trong những cái bẫy tuning JVM tốn kém nhất.

1. Compressed OOP — nén con trỏ để cứu heap

OOP (Ordinary Object Pointer) là con trỏ JVM dùng để tham chiếu một object trên heap. Trên JVM 64-bit, một con trỏ đầy đủ là 8 byte. Object nhiều reference field trả giá nặng: một HashMap.Node có ba reference (key, value, next) tốn 24 byte chỉ riêng con trỏ.

Compressed OOP biểu diễn mỗi reference bằng 32 bit (4 byte). Bật bằng -XX:+UseCompressedOops, và mặc định bật trên JVM 64-bit khi heap dưới 32 GB (từ JDK 6u23). Lợi ích:

• Mỗi reference field: 8 byte xuống 4 byte.
• Klass pointer — con trỏ trong object header trỏ tới metadata của class (bài 09) — cũng 8 xuống 4 byte, nhưng do cờ riêng UseCompressedClassPointers (xem §6), thường cùng bật với compressed OOP.
• Mỗi slot trong array of reference: 8 xuống 4 byte.

Với object điển hình (nhiều reference), tổng tiết kiệm thường 20-40% heap (một HashMap.Node tiết kiệm 33%, một String 25% — xem §5) — đủ để một app 40 GB uncompressed gói gọn quanh 28-30 GB compressed.

2. Cơ chế — vì sao 32 bit lại trỏ được vùng nhớ 64-bit?

Hình dung một khu phố mà mọi nhà chỉ được đánh số bội 8: 0, 8, 16, 24… Số nào cũng tận cùng bằng ba chữ số nhị phân 000, nên khi ghi sổ ta bỏ luôn ba số đó — lưu "1, 2, 3" thay cho "8, 16, 24" cho gọn, cần địa chỉ thật thì nhân lại 8. Compressed OOP làm y hệt với con trỏ object.

Mẹo nằm ở alignment. Bài 09 đã chỉ ra mọi object HotSpot align 8 byte, nên địa chỉ thực của bất kỳ object nào luôn chia hết cho 8 — tức 3 bit thấp luôn bằng 0. Ba bit đó không mang thông tin, nên JVM bỏ chúng khi lưu và khôi phục khi dùng:

compressed = (actual_address - heap_base) >> 3
actual     = heap_base + (compressed << 3)

Dịch phải 3 bit khi nén, dịch trái 3 bit khi giải nén. heap_base là địa chỉ gốc của heap; thường bằng 0 ở zero-based mode — khi JVM đặt được heap bắt đầu ngay tại địa chỉ 0, phép trừ heap_base biến mất và giải nén chỉ còn một phép dịch trái, nhanh hơn.

Áp công thức: actual = 0 + (1000 << 3) = 1000 × 8 = 8000. Object nằm ở byte 8000. Mỗi bước tăng 1 của giá trị compressed tương ứng nhảy 8 byte trong heap thực — đó là lý do một con trỏ 32 bit "với tới" được vùng nhớ rộng gấp 8 lần chính nó.

3. Vì sao trần đúng 32 GB?

Giờ tự suy ra giới hạn:

Phép tính: 2^32 giá trị nhân 8 byte mỗi bước = 2^32 × 2^3 = 2^35 byte. Mà 2^35 = 34,359,738,368 byte = 32 GB. Đây là trần toán học — không thể tăng nếu không thêm bit hoặc đổi alignment.

Có một cách nới trần: tăng alignment. -XX:ObjectAlignmentInBytes=16 khiến mỗi bước compressed nhảy 16 byte, phủ 2^32 × 16 = 2^36 = 64 GB. Nhưng đổi lại mỗi object tốn padding nhiều hơn — hiếm khi lời, nên gần như không ai dùng.

4. Khi nào compressed OOP tắt?

JVM kiểm tra heap size lúc khởi động. Nếu -Xmx đủ nhỏ để 32-bit con trỏ phủ hết heap, nó bật compressed OOP; nếu heap lớn hơn trần, nó tắt vì con trỏ 32 bit không còn địa chỉ hoá đủ.

Ngưỡng thực tế thấp hơn 32 GB một chút. JVM cần một vùng địa chỉ nhỏ cho cấu trúc nội bộ, nên compressed OOP thường tắt sớm hơn mốc 32 GB chính xác — ngưỡng an toàn thực tế khoảng 30-31 GB. Kiểm tra với heap cụ thể:

java -Xmx31g -XX:+PrintFlagsFinal -version | grep UseCompressedOops
# UseCompressedOops = true   -> con tri
java -Xmx33g -XX:+PrintFlagsFinal -version | grep UseCompressedOops
# UseCompressedOops = false  -> da tat

5. 32GB cliff — cái bẫy đắt nhất khi chọn heap size

Đây là hệ quả phản trực giác: heap to hơn có thể chứa ít object hơn. Khi compressed OOP tắt, mọi reference và klass pointer nhảy từ 4 lên 8 byte, kéo mọi object nhiều reference phình 30-50%.

Trước khi xem ví dụ chốt, tự dựng con số:

Đáp án:

Compressed OOP (heap 31 GB):
  mark 8 + klass 4 + hash 4 + next 4 + key 4 + value 4 = 28 -> pad 4 -> 32 byte

Uncompressed OOP (heap 33 GB):
  mark 8 + klass 8 + hash 4 + pad 4 + next 8 + key 8 + value 8 = 48 byte

Node phình từ 32 lên 48 byte — tăng 50% (chính là mặt kia của "tiết kiệm 33%" nêu ở §1: cùng một chênh lệch 16 byte, chỉ khác lấy 48 hay 32 làm mẫu số). Quy ra sức chứa (dùng GiB nhất quán với -Xmx…g và trần 2^35):

• Heap 31 GiB compressed: nếu chỉ đựng node, 31 GiB / 32 B ≈ 1.04 tỷ node.
• Heap 33 GiB uncompressed: 33 GiB / 48 B ≈ 738 triệu node — ít hơn dù heap to hơn 2 GiB.

Cùng cơ chế xảy ra với String (Java 9+ compact): 24 byte compressed lên 32 byte uncompressed — tăng 33%, chưa kể byte[] đi kèm. App cache 100 triệu String: 2.4 GB so với 3.2 GB chỉ riêng phần object.

flowchart TD
    A["Chon -Xmx cho app"] --> B{"Heap duoi ~32 GB?"}
    B -->|"Co"| C["Compressed OOP BAT<br/>ref 4 byte, object nho"]
    B -->|"Khong"| D["Compressed OOP TAT<br/>ref 8 byte, object phinh 30-50%"]
    D --> E{"Co that su can rat nhieu heap?"}
    E -->|"Chua toi 64 GB"| F["32GB cliff: worst of both worlds<br/>giam ve 30-31 GB"]
    E -->|"Rat lon"| G["Nhay thang 64 GB+<br/>hoac dung ZGC"]

6. Compressed Class Pointer — một cờ riêng

Klass pointer trong header có cờ riêng biệt với compressed OOP: -XX:+UseCompressedClassPointers. Khi bật (mặc định khi heap nhỏ), klass pointer chỉ 4 byte, và JVM dồn mọi Klass struct vào một vùng riêng — Compressed Class Space (mặc định 1 GB, chỉnh bằng -XX:CompressedClassSpaceSize).

Từ JDK 15 hai cờ được tách độc lập (trước đó UseCompressedClassPointers buộc phải đi kèm UseCompressedOops). Ví dụ điển hình: ZGC dùng colored pointer cho reference (không nén OOP) nhưng vẫn nén klass pointer để mỗi object nhỏ đi 4 byte. Tuy vậy trên collector mặc định (G1), khi heap vượt 32 GB thì compressed OOP tắt thường kéo class pointer tắt theo, nên cả reference lẫn klass pointer đều phình.

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

• Bài 09 — Object header & field layout: nền của bài này — header 12 byte, klass pointer 4 byte, quy tắc align 8 byte chính là điều kiện để compressed OOP hoạt động.
• Bài 05 — Memory: heap & metaspace: heap là vùng compressed OOP địa chỉ hoá; đặt -Xmx quanh 32 GB tác động trực tiếp tới footprint.
• Bài 12 — GC hiện đại: ZGC dùng colored pointer, không bị 32GB cliff — cách khác để chạy heap rất lớn mà không trả giá pointer.

8. Tóm tắt

• Compressed OOP nén reference và klass pointer 8 byte xuống 4 byte, tiết kiệm khoảng 20-40% heap; mặc định bật khi heap dưới 32 GB.
• Cơ chế: object align 8 byte nên 3 bit thấp của địa chỉ luôn 0 — bỏ 3 bit đó, dịch phải khi nén, dịch trái khi giải nén.
• Trần 32 GB = 2^32 giá trị nhân 8 byte = 2^35 byte. Tăng alignment lên 16 nới lên 64 GB nhưng tốn padding, hiếm dùng.
• 32GB cliff: vượt ngưỡng, compressed OOP tắt, object phình 30-50%; heap 31 GB compressed chứa nhiều object hơn 33 GB uncompressed.
• Chọn heap size: cần dưới 31 GB giữ 30-31 GB; cần hơn nhảy thẳng 64 GB, tránh vùng 33-50 GB.
• Compressed class pointer là cờ riêng, dùng Compressed Class Space (mặc định 1 GB), thường cùng trạng thái với compressed OOP.

9. Tự kiểm tra

Bài tiếp theo: Escape Analysis và Scalar Replacement — khi JIT xoá object trước khi bạn tạo nó