JIT compiler — interpreter, C1, C2 và tiered compilation

TL;DR: JVM không chạy bytecode một cách cố định. Nó bắt đầu ở interpreter (đọc từng bytecode, chậm nhất), đếm số lần mỗi method chạy bằng invocation counter và back-edge counter, rồi khi method "nóng" thì biên dịch sang native code: C1 (compile nhanh, tối ưu vừa, khoảng 200 lần gọi) trước, C2 (compile chậm, tối ưu sâu, khoảng 5000 lần gọi) sau. Đó là tiered compilation — nhiều tier chạy song song, method leo tier theo profile runtime. Với vòng lặp chạy tỷ vòng trong một lần gọi, JVM dùng OSR (On-Stack Replacement) để thay khung interpreter bằng native ngay giữa vòng lặp. Đây là lý do Java "khởi động chậm nhưng chạy nhanh".

Một benchmark kinh điển:

long sum = 0;
for (int i = 0; i < 1_000_000_000; i++) {
    sum += i;
}

Lần đầu chạy trên JVM vừa khởi động (cold): khoảng 3 giây. Chạy lại đúng vòng lặp đó trong cùng JVM (warm): khoảng 0.3 giây. Code y hệt, JVM y hệt — nhanh gấp 10 lần. Thủ phạm là JIT compiler: JVM profile code lúc chạy, phát hiện method nóng, biên dịch bytecode thành native machine code, rồi dùng bản native cho các lần sau. Càng nóng, JVM càng đầu tư compile sâu hơn.

Bài này trace đường đi của một method qua các tier — interpreter, C1, C2 — cùng cơ chế counter kích hoạt compile và OSR cho vòng lặp. Các tối ưu bên trong C2 (inlining, devirtualization) và cách chẩn đoán deoptimization để dành cho hai bài kế tiếp.

1. Analogy — ba chế độ của người đầu bếp

Bạn mở quán ăn. Người đầu bếp có ba chế độ làm việc, và theo dõi tần suất từng món — món lên hot thì leo chế độ cao hơn:

• Interpreter — đọc công thức từng dòng trong sách rồi làm theo. Đúng nhưng chậm. Phù hợp món hiếm khách gọi, không đáng công ghi nhớ.
• C1 (compile nhanh) — sau vài lần, đầu bếp ghi quy trình rút gọn ra tờ ghi chú riêng, không cần mở sách. Nhanh hơn khoảng 3 tới 5 lần, nhưng chưa tối ưu kỹ.
• C2 (tối ưu sâu) — với món bán chạy, đầu bếp cắt sẵn nguyên liệu, biến thành phản xạ cơ bắp, bỏ mọi bước thừa. Nhanh hơn khoảng 10 tới 20 lần; chuẩn bị lâu nhưng gần tối ưu.

2. Vì sao JIT thay vì AOT?

AOT (Ahead-of-Time) biên dịch bytecode sang native ngay lúc build, giống C compile thẳng ra .exe: khởi động nhanh, không warm-up, nhưng thiếu profile runtime nên tối ưu kém hơn ở trạng thái ổn định. JIT (Just-in-Time) biên dịch lúc chạy, có profile thật: tối ưu quyết liệt dựa trên giả định "trường hợp này xảy ra 99%", đổi lại warm-up chậm.

JVM truyền thống chọn JIT vì Java nhắm tới server chạy dài hạn — vài giây warm-up đổi lấy throughput cao hàng giờ là một đổi chác tốt. Với serverless và CLI (nơi startup quan trọng hơn peak), hệ sinh thái Java có GraalVM Native Image đi theo hướng AOT — chuyện đó thuộc bài 04c.

3. Ba tier: interpreter, C1, C2

HotSpot (OpenJDK mainstream) có năm mức tier nhưng thực dụng chỉ cần ba nhóm:

Tier 1 tới 3 đều là biến thể C1 với mức profile khác nhau (tier 3 sinh thêm profiling data để C2 dùng sau). Thực dụng không cần phân biệt sâu.

3.1 Counter kích hoạt compile

Mỗi method có hai bộ đếm:

• Invocation counter — đếm số lần method được gọi.
• Back-edge counter — đếm số lần một vòng lặp trong method quay lại đầu vòng (mỗi lần lặp là một back-edge).

Khi counter vượt ngưỡng, JVM submit method cho compile thread. Ngưỡng mặc định (Java 21, chế độ tiered) do các cờ HotSpot điều khiển:

• Interpreter lên C1: khoảng 200 lần gọi (Tier3InvocationThreshold).
• C1 lên C2: khoảng 5000 lần gọi (Tier4InvocationThreshold).

Với vòng lặp nóng, back-edge counter tăng rất nhanh: một vòng lặp chạy hàng trăm triệu lần có thể đẩy method lên C2 trong chưa tới một giây.

3.2 Compile chạy trên thread nền

JIT compile là bất đồng bộ: compile thread riêng biệt, không chặn app thread. Trong lúc compile thread sản xuất native code, app thread vẫn tiếp tục chạy bản interpreter. Khi native code xong, JVM tráo callsite từ interpreter sang native — lần chạy tiếp theo dùng bản native.

flowchart LR
    A["Method moi"] -->|"0 lan goi"| B["Interpreter (tier 0)"]
    B -->|"~200 lan goi"| C["C1 compile (tier 3)"]
    C -->|"~5000 lan goi"| D["C2 compile (tier 4)"]
    D -->|"on dinh"| D

    style B fill:#93C5FD
    style C fill:#FCD34D
    style D fill:#6EE7B7

Số compile thread mặc định phụ thuộc số core (tune bằng -XX:CICompilerCount=N). Vì compile không chặn app, warm-up là quá trình mượt: throughput tăng dần khi từng method nóng leo tier.

4. OSR — On-Stack Replacement

Xét một method chỉ được gọi một lần nhưng chứa vòng lặp chạy hàng tỷ vòng:

void compute() {
    for (int i = 0; i < 1_000_000_000; i++) {
        // hot loop
    }
}

Invocation counter chỉ đếm được 1 — không bao giờ chạm ngưỡng để compile theo cách thường. Nếu chỉ dựa vào invocation counter, cả vòng lặp tỷ vòng này sẽ chạy hoàn toàn ở interpreter.

Đây là lúc back-edge counter vào cuộc. Sau vài chục nghìn vòng lặp (ngưỡng back-edge tier 4 mặc định khoảng 40.000 ở Java 21), JVM nhận ra vòng lặp đang nóng. Vướng mắc: method vẫn đang chạy dở — khung của nó nằm trên stack, không thể "gọi lại" để dùng bản native như method thường.

Giải pháp là OSR (On-Stack Replacement): JIT compile riêng phần vòng lặp (điểm vào là back-edge offset trong bytecode), dựng một "OSR adapter" chuyển trạng thái khung interpreter (local variable, operand stack) sang khung native, rồi tại một safepoint ở back-edge tráo khung interpreter thành khung native ngay giữa vòng lặp — vòng lặp chạy tiếp bằng native từ đúng vòng đang dở, giữ nguyên state.

Trong JIT log, một compile OSR trông như:

1234   42 % 4   com.foo.Bar::compute @ 12 (123 bytes)

Ký hiệu % đánh dấu đây là OSR; @ 12 là bytecode offset của back-edge kích hoạt; 4 là tier (C2). (Cách đọc đầy đủ các cột JIT log nằm ở bài 04c.)

5. Sau khi vào C2 — những tối ưu tiếp theo

Khi method đã lên C2, phần lớn tăng tốc đến từ inlining (dán thân callee vào caller để bỏ overhead lời gọi và mở ra tối ưu xuyên biên) và devirtualization (biến lời gọi ảo thành lời gọi trực tiếp qua inline cache và type profile) — trọng tâm của bài 04b. C2 còn có escape analysis (phân rã object không thoát method thành biến trên stack, bỏ hẳn cấp phát heap), đã được mổ đầy đủ ở bài 10 nên bài này không lặp lại.

6. Pitfall — đo sai vì chưa warm-up

Sai lầm phổ biến nhất khi làm việc với JIT là benchmark khi code còn ở interpreter:

long t1 = System.nanoTime();
hotMethod();                 // lan dau: interpreter, cham ~10x
long t2 = System.nanoTime();
System.out.println((t2 - t1) / 1000 + "us");  // do interpreter time, vo nghia

Kết quả này đo tốc độ interpreter, không phản ánh performance ở trạng thái ổn định. Cách đúng: dùng JMH (Java Microbenchmark Harness) — framework chuẩn của OpenJDK, tự warm-up (chạy nhiều vòng cho JIT leo tier) rồi mới đo, và tự chống dead-code elimination và constant folding.

Hệ quả production: app vừa khởi động có throughput thấp vài chục giây đầu vì mọi thứ còn ở interpreter hoặc C1 — nên pre-warm bằng synthetic traffic trước khi route real traffic vào instance mới. Chi tiết warm-up problem và các chiến lược giảm nó (CDS, AOT, native image) nằm ở bài 04c.

7. Deep Dive

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

• Bài 04b — Inlining và devirtualization: các tối ưu chính bên trong C2 sau khi method lên tier 4.
• Bài 04c — Deoptimization, JIT log và warm-up: khi giả định của JIT sai thì JVM undo thế nào, cách đọc JIT log, và các chiến lược giảm warm-up.
• Bài 10 — Escape analysis: tối ưu C2 xoá cấp phát object không thoát method — đích tham chiếu của §5.
• Bài 02 — Class file và javap: bytecode mà JIT nhận làm đầu vào; hiểu bytecode giúp đọc JIT log ở bài 04c.

9. Tóm tắt

• JVM chạy bytecode qua các mức: interpreter (chậm nhất, không compile) leo lên C1 (compile nhanh, tối ưu vừa) rồi C2 (compile chậm, tối ưu sâu). Đây là tiered compilation — nhiều tier chạy song song, method nóng leo tier theo profile.
• Ngưỡng mặc định Java 21: khoảng 200 lần gọi lên C1, 5000 lên C2. Con số 10.000 là CompileThreshold non-tiered cũ, không phải mặc định tiered. Invocation counter (số lần gọi) và back-edge counter (số vòng lặp) kích hoạt compile.
• Compile chạy trên thread nền, không chặn app thread — warm-up là quá trình tăng throughput mượt dần.
• OSR (On-Stack Replacement): compile riêng phần vòng lặp và tráo khung interpreter thành native ngay giữa vòng lặp, nhờ back-edge counter — không đợi method được gọi lại.
• Đo performance phải ở trạng thái ổn định sau warm-up; dùng JMH thay vì tự đo bằng System.nanoTime().

10. Tự kiểm tra

Bài tiếp theo: Inlining và devirtualization — hai tối ưu chính của C2