JIT compiler — interpreter, C1, C2, tiered compilation

Benchmark cũ kinh điển:

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

Lần đầu chạy (cold JVM): ~3 giây. Chạy lại trong cùng JVM (warm): ~0.3 giây. Code y hệt, JVM y hệt — khác biệt 10x.

Câu trả lời: JIT compiler. JVM không thực thi bytecode trực tiếp như interpreter chạy script. Nó profile code khi chạy, phát hiện method "nóng" (gọi nhiều), compile bytecode → native machine code, dùng native code lần sau. Càng nóng càng compile sâu hơn.

JIT là lý do Java đạt performance gần C/C++ trong steady state — đôi khi vượt vì JIT có thông tin runtime mà compiler tĩnh không có (vd "method này 100% case nhận argument null", "branch này không bao giờ vào"). Nhưng cũng là lý do Java nổi tiếng "warm-up chậm" — code mới chạy còn ở interpreter, vài giây mới lên hot.

Bài này đi qua: 3 tier (interpreter → C1 → C2), trigger compile (counter, OSR), 3 optimization quan trọng (inlining, escape analysis, devirtualization), deoptimization (khi assumption sai, JIT undo), và cách đọc JIT log để debug.

1. Analogy — Sách công thức nấu ăn

Bạn mở quán ăn. Đầu bếp có 3 chế độ làm việc:

Tier 0 — Interpreter: với mỗi món, đầu bếp đọc công thức từng dòng từ sách, làm theo. Đúng nhưng chậm — đọc sách + làm + đọc sách + làm. Phù hợp món hiếm khách gọi (1 lần/ngày).

Tier 3 — C1 (fast compile): sau khi làm 1 món vài lần, đầu bếp ghi lại quy trình ngắn ra notebook riêng — không cần mở sách. Nhanh hơn 3-5 lần. Compile nhanh nhưng optimize ít.

Tier 4 — C2 (deep optimize): với món "best-seller" (gọi 100+ lần/giờ), đầu bếp đầu tư công sức optimize: pre-cut nguyên liệu, đặt thành routine cơ bắp, bypass mọi step không cần. Nhanh hơn 10-20 lần. Compile chậm nhưng kết quả gần optimal.

Đầu bếp theo dõi tần suất từng món. Món lên hot → escalate tier. Món tier cao bỗng nhận argument lạ (giả sử khách yêu cầu vegan version) → đầu bếp deoptimize xuống tier 0, làm lại từ sách, học pattern mới.

2. Vì sao JIT thay vì AOT (compile trước)?

AOT (Ahead-of-Time): compile bytecode → native lúc build. Like C compile thẳng .exe. Ưu: startup nhanh (no warm-up). Nhược: thiếu profile runtime, optimize kém hơn JIT trên steady state.

JIT (Just-in-Time): compile khi chạy, có profile thực. Ưu: optimize aggressive với assumption "case này 99% xảy ra". Nhược: warm-up chậm.

JVM truyền thống chọn JIT vì Java target server long-running — vài giây warm-up đổi lấy throughput cao hàng giờ là deal tốt.

Recent: GraalVM Native Image (AOT cho Java) cho serverless / CLI — không warm-up, startup <100ms. Trade-off peak performance thấp hơn HotSpot JIT 10-20%.

3. 3 tier compilation

HotSpot JVM (mainstream OpenJDK) có 5 tier nhưng practical là 3:

(Tier 2 và 3 là biến thể C1 với mức profile khác nhau — không cần phân biệt practical.)

Flow điển hình

flowchart LR
    A[Method new] -->|0 invocation| B[Interpreter]
    B -->|hot threshold ~1500| C[C1 compile]
    C -->|hotter ~10000| D[C2 compile]
    D -->|assumption fail| B
    D -->|stable| D

Counter: mỗi method có invocation counter + back-edge counter (loop). Vượt threshold → submit cho compile thread.

Threshold default (tunable):

• Interpreter → C1: ~1500 invocation.
• C1 → C2: ~10000 invocation.

Nhỏ với loop nóng. Có thể thấy code đạt C2 trong < 1 giây nếu loop chạy hàng trăm triệu lần.

Compile thread pool

JIT compile background: thread compiler riêng biệt, không block app thread. App thread tiếp tục chạy interpreter trong khi compile thread sản xuất native code. Khi xong, JVM swap callsite từ interpreter → native — dòng code tiếp theo dùng native.

Số compile thread default ~4 (tuỳ #core). Tune bằng -XX:CICompilerCount=N.

OSR — On-Stack Replacement

Method lớn có loop chạy hàng tỷ iteration → đếm theo invocation không kịp escalate (mới gọi 1 lần). JVM dùng back-edge counter (đếm vòng lặp).

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

Sau ~10000 iteration, JIT nhận biết loop nóng. Vấn đề: method vẫn đang chạy giữa loop → không thể "replace" method bình thường (frame đang trên stack).

Giải pháp: OSR (On-Stack Replacement) — JIT compile loop riêng, swap thẳng frame interpreter → frame native giữa loop. Loop tiếp tục với native code, state preserved.

Trong JIT log thấy:

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

% đánh dấu OSR. @ 12 là bytecode offset (back-edge) trigger.

4. 3 optimization quan trọng

4.1 Inlining — quan trọng nhất

Inline = paste body callee vào caller, bỏ call overhead.

int square(int x) { return x * x; }
int sumOfSquares(int n) {
    int sum = 0;
    for (int i = 0; i < n; i++) {
        sum += square(i);   // Goi method
    }
    return sum;
}

C2 inline:

int sumOfSquares(int n) {
    int sum = 0;
    for (int i = 0; i < n; i++) {
        sum += i * i;       // Inline
    }
    return sum;
}

Lợi ích:

• Loại bỏ method call overhead (push frame, pop frame).
• Mở ra optimize across boundary: register allocation tốt hơn, constant fold, dead code elimination, loop invariant hoisting.

Threshold: method ≤ 35 byte (default) → "always inline candidate". Method > 325 byte → "never inline" (quá lớn, code bloat). Giữa thì tuỳ counter.

final method, static, private dễ inline hơn — không cần devirtualize.

4.2 Escape analysis

JIT phân tích: object có "escape" khỏi method scope không? Nếu không (chỉ dùng trong method, không lưu field, không return, không pass thread khác) → có thể stack-allocate thay heap.

String greet(String name) {
    StringBuilder sb = new StringBuilder();
    sb.append("Hi, ");
    sb.append(name);
    return sb.toString();
}

sb không escape (chỉ dùng nội bộ, return là String mới). C2 nhận biết → không alloc StringBuilder trên heap. Field char[] có thể alloc trên stack hoặc inline thẳng vào local register. Loại bỏ allocation cost + GC pressure.

Trong production, escape analysis có thể save 30-50% allocation cho code dùng builder/wrapper pattern. Lý do code Java idiomatic không "chậm" như C++ developer hay nghĩ.

4.3 Devirtualization

Java invokevirtual cần lookup vtable runtime. JIT optimize: nếu nhìn thấy chỉ 1 implementation trong runtime profile, inline direct.

List<Integer> list = ...;        // Static type List
list.forEach(System.out::println);  // invokeinterface

Profile: list luôn là ArrayList. JIT speculate "luôn ArrayList", inline ArrayList.forEach. Insert type check (guard): if not ArrayList → fall back interpreter.

// JIT-compiled native code (pseudo):
if (list.getClass() != ArrayList.class) goto deopt;
// Inline ArrayList.forEach body...

Type check: 1 instruction (so klass pointer). Nếu fail → deoptimize, đi lại interpreter, learn case mới.

Đây là lý do monomorphic call site (1 type) cực nhanh, polymorphic (2-3 type) vẫn nhanh (chained inline cache), megamorphic (vượt 3 type) chậm hơn (full vtable lookup).

Code design tip: tránh interface với hàng chục implementation trong hot path. Mỗi callsite chỉ thấy ít type → JIT optimize tốt.

5. Deoptimization — khi JIT undo

JIT compile dựa trên assumption từ profile. Khi assumption sai, JIT phải undo — quay lại interpreter, học case mới.

Trigger deopt

• Type không khớp speculative: code đang chạy ArrayList, bỗng có LinkedList → speculative inline vỡ.
• Branch chưa thấy: code có if (rare) mà profile chưa thấy nhánh true → JIT compile chỉ nhánh false + uncommon trap. Khi rare = true runtime → trap → deopt.
• Class load mới: subclass mới load có thể override method được inline. JVM invalidate code cũ.
• Assertion JVM internal: vd assertion về object layout không còn đúng.

Cost deopt

Deopt là rất đắt:

1. Native frame phải convert lại thành interpreter frame (rebuild local + stack).
2. Mã native compile bị throw đi.
3. Method quay về interpreter — chậm hàng chục lần.
4. Nếu method vẫn nóng, sẽ recompile sau vài nghìn invocation thêm.

App pattern xấu: deopt liên tục (vd type biến đổi mỗi vài giây) → JIT thrash, performance không bao giờ steady.

-XX:+PrintCompilation

Bật để xem JIT activity:

java -XX:+PrintCompilation MyApp

Output:

   123    1     b      java.lang.String::hashCode (49 bytes)
   145    2     n      java.lang.Object::getClass (native)
   201    3       3   com.foo.Bar::process (12 bytes)
   312    4       4   com.foo.Bar::process (12 bytes)
   456    3       3   com.foo.Bar::process (12 bytes)   made not entrant
   457    5       4   com.foo.Bar::process (12 bytes)

Cột:

• Timestamp (ms từ JVM start).
• Compile ID.
• Flag: b blocking, n native, s synchronized, ! exception, % OSR, made not entrant (deopt), made zombie (cleanup).
• Tier (3 = C1, 4 = C2).
• Method + bytecode size.

Trong ví dụ: process compile C1 (tier 3) lúc 201ms, C2 (tier 4) lúc 312ms. Sau đó "made not entrant" — invalidate. Recompile lúc 457ms.

6. Inline cache và type profile

Callsite invokevirtual được JIT track type seen:

Monomorphic (1 type seen):
  Inline target.
  Insert type check, fail -> deopt.

Bimorphic (2 type seen):
  Inline cache 2 chain.
  type1 -> target1, type2 -> target2.
  3rd type -> deopt.

Polymorphic (3+ type):
  Convert to megamorphic.
  Full vtable lookup mỗi call (chậm).

Code "stable type" (luôn cùng class) → JIT đầu tư inline. Code "type Đa dạng" → JIT bỏ optimize, dùng vtable.

Tip: type-stable callsite

// Stable - tot
for (Order order : orders) {
    order.calculate();        // order luon cung type cu the (vd OrderImpl)
}

// Megamorphic - cham
for (Animal animal : zoo) {
    animal.sound();           // Dog, Cat, Bird, ... xen ke
}

Performance nhánh 2 chậm hơn ~3-5x do vtable lookup mỗi call. Workaround: dispatch theo type batch:

groupBy(animals, Animal::getClass).forEach((cls, list) -> {
    list.forEach(Animal::sound);   // Trong batch, callsite monomorphic
});

Hoặc redesign: tách Dog list, Cat list riêng — mỗi callsite type cố định.

7. JIT log — debug performance

-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining

In quyết định inline:

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining MyApp 2>&1 | grep -A2 'process'

Output:

@ 5   java.util.ArrayList::size (5 bytes)   inline (hot)
@ 12  com.foo.Bar::validate (8 bytes)        inline (hot)
@ 28  com.foo.Bar::log (95 bytes)            too big
@ 45  com.foo.Bar::handleCase (250 bytes)    callee is too large

Lý do "too big" → -XX:MaxInlineSize=N tune, hoặc refactor method nhỏ hơn.

-XX:+LogCompilation

Dump XML chi tiết về compile decision. Phân tích bằng tool như JITWatch (https://github.com/AdoptOpenJDK/jitwatch).

JITWatch UI: thấy method nào compile tier nào, deopt khi nào, lý do, suggest tune.

JFR event

JFR (Java Flight Recorder, bài 6) capture compilation event:

• jdk.Compilation — mỗi lần compile.
• jdk.CompilerInlining — quyết định inline.
• jdk.Deoptimization — mỗi deopt với lý do.

Production-safe: JFR overhead < 1%, có thể bật always-on.

8. AOT và CDS — bổ trợ JIT

JIT không phải solution duy nhất. JVM có 2 feature giảm warm-up:

CDS (Class Data Sharing) — JEP 310

Pre-load core JDK class vào shared archive (.jsa file), map vào memory mỗi JVM start. Bypass class loading + linking.

# Tao archive cho app
java -XX:ArchiveClassesAtExit=app.jsa -jar myapp.jar

# Chay voi archive
java -XX:SharedArchiveFile=app.jsa -jar myapp.jar

Startup nhanh hơn ~30-50% cho CLI / serverless. Spring Boot 3.3+ tích hợp tự động.

AOT JIT cache — JEP 483 (Java 24, preview)

Pre-compile hot method ra cache trên đĩa. Lần JVM sau load cache → có sẵn native code, skip warm-up.

Trade-off: cache phụ thuộc CPU + JVM version. Không chia sẻ được giữa máy khác.

GraalVM Native Image

Compile toàn bộ app thành native binary, không JVM runtime. Startup <100ms. Memory footprint nhỏ. Phù hợp serverless (AWS Lambda).

Trade-off:

• Peak performance ~10-20% thấp hơn HotSpot JIT (no profile-guided optimize).
• Reflection / dynamic class loading khó (cần config trước).
• Build time chậm (~vài phút).

Spring Boot 3 + Quarkus + Micronaut hỗ trợ Native Image tốt.

9. Pitfall tổng hợp

❌ Nhầm 1: Benchmark chưa warm-up.

long t1 = System.nanoTime();
hotMethod();
long t2 = System.nanoTime();
System.out.println((t2 - t1) / 1000 + "us");   // Do interpreter time, vo nghia

✅ Dùng JMH (bài Module 13). Tự warm-up + measure đúng.

❌ Nhầm 2: Method "lạnh" tưởng nhanh vì code đơn giản.

String.equals chay tren cold path = 100x cham hon hot path.

✅ Kiểm performance ở steady state, không lần đầu.

❌ Nhầm 3: Method quá lớn không inline được.

void doEverything() { /* 500 dong */ }   // Khong inline -> caller cham

✅ Tách method nhỏ. JVM inline tốt hơn nhiều method nhỏ vs 1 method to.

❌ Nhầm 4: Catch exception trong hot loop.

for (int i = 0; i < n; i++) {
    try { ... } catch (Exception e) { ... }   // JIT bỏ optimize
}

✅ Move try ngoài loop, hoặc validate trước thay vì catch.

❌ Nhầm 5: Megamorphic callsite trong hot path.

for (Item item : items) {
    item.process();   // 10 type khac nhau -> vtable lookup mỗi call
}

✅ Group by type, hoặc redesign avoid polymorphism trong hot path.

❌ Nhầm 6: Tin "Java luôn chậm hơn C++".

Steady state: Java 90-110% C++ throughput trong nhiều benchmark.
Cold: chậm hơn 10x.

✅ Đo trên use case thực — đúng workload, đúng warm-up.

10. 📚 Deep Dive Oracle

11. Tóm tắt

• JVM execute bytecode qua tầng: Interpreter (chậm nhất, no compile) → C1 (compile nhanh, optimize ít) → C2 (compile chậm, optimize sâu).
• Tiered compilation: chạy đa tier song song. Method nóng escalate. Threshold ~1500 (C1), ~10000 (C2) invocation.
• Counter: invocation counter + back-edge counter (loop) trigger compile.
• OSR (On-Stack Replacement): compile loop khi method đang chạy, swap frame interpreter → native giữa loop.
• Inlining: optimize quan trọng nhất. Method ≤ 35 byte luôn inline. Method > 325 byte không inline.
• Escape analysis: object không escape method scope → stack-allocate, save GC pressure.
• Devirtualization: callsite monomorphic (1 type) inline direct + type guard. Bimorphic chained inline cache. Megamorphic full vtable lookup chậm hơn 3-5x.
• Deoptimization: assumption sai (type không match, branch chưa thấy, class mới load) → JIT undo, quay interpreter. Đắt — tránh thrashing.
• -XX:+PrintCompilation: log mỗi compile event. -XX:+PrintInlining log inline decision.
• JFR capture compilation + deopt event với overhead < 1% — production safe.
• CDS giảm startup time bằng share class archive.
• GraalVM Native Image AOT toàn app — startup <100ms, peak performance thấp 10-20%.
• Code design: keep hot method nhỏ, callsite type-stable, tránh exception trong hot loop.
• Java cold = chậm 10x, Java warm = gần C++. Đo ở steady state với JMH.

12. Tự kiểm tra

long t1 = System.nanoTime();
hotMethod();   // Lan dau, interpreter, ~10x cham
long t2 = System.nanoTime();
print(t2 - t1);   // Sai - do co interpreter time

// Truoc inline
int sum(int n) {
  int s = 0;
  for (int i = 0; i < n; i++) s += square(i);
  return s;
}
int square(int x) { return x * x; }

// Sau inline
int sum(int n) {
  int s = 0;
  for (int i = 0; i < n; i++) s += i * i;
  return s;
}

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

Bài tiếp theo: Memory layout — heap, metaspace, stack, object header