Understand JIT Compilation in the JVM: Interpret -> C1 -> C2

Topic Overview

Tiered JIT in HotSpot

The JVM starts in the interpreter, then promotes hot methods through C1 (fast, lightly optimized) to C2 (aggressive optimizing). Tiered compilation balances startup time against peak throughput.

The Pipeline

Typical progression:

1. Interpreter: zero compile cost, high per-bytecode overhead
2. C1 (client): quick native code, some inlining and profiling hooks
3. C2 (server): full optimization after counters prove a method is hot

Method invocation counters and back-edge counters trigger compilation. OSR (on-stack replacement) compiles loops inside long-running methods without waiting for the next entry.

For example, a server loop may run interpreted for thousands of iterations, hit C1, then C2 with inlined callees and escape analysis.

Flags like \`-XX:+TieredCompilation\` control the policy on modern JDKs.

Design Notes

Compile thresholds exist because compiling everything at startup would slow launch unbearably. Server workloads benefit from higher thresholds; interactive apps sometimes lower them for snappier first interactions.

For This Exercise

This exercise asks you to document the interpret-to-C1-to-C2 pipeline. You will explain what triggers each tier and why cold code stays interpreted while hot paths get native code.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.

Your Task

Simulate HotSpot's tiered compilation policy. Methods start in the interpreter (level 0), get compiled by C1 with profiling (level 3) once warm, or by C1 without profiling (level 1) if trivial, and by C2 (level 4) once hot. Long-running loops trigger OSR (on-stack replacement) compiles. An uncommon trap in C2 code deoptimizes the method back to the interpreter, and a method that traps too often is barred from C2. Print a -XX:+PrintCompilation-style log.

Input

# starts a comment.

cCopy
Loading…

Policy

Each method has counters inv and back, which reset to 0 whenever it is compiled at a new level (not for OSR). A global tick increases by 1 per invocation and per back-edge.

• Invocation (tick++, inv++, then check):
  • at level 0: if inv >= 200, or inv >= 100 && inv + back >= 2000, compile at level 1 if trivial, else at level 3;
  • at level 3 (and not barred from C2): if inv >= 5000, or inv >= 1000 && inv + back >= 15000, compile at level 4.
• Back-edge (tick++, back++, then check):
  • at level 0 with back >= 10000 and no OSR code at level ≥ 3: OSR compile at level 3;
  • at level 3 (not barred) with back >= 40000 and no OSR code at level 4: OSR compile at level 4.
• Compile IDs count from 1 across all compiles, including OSR.
• Replacement: a normal compile replaces the previous normal code, which is then reported made not entrant.
• trap (level 4 only; otherwise trap REASON: ignored, NAME is not running C2 code):
  1. print uncommon trap in NAME: REASON -> deoptimize;
  2. mark the C2 code not entrant;
  3. go back to level 0 with the counters reset, dropping any level-4 OSR code;
  4. on the second trap, print NAME: too many traps, not compilable at level 4, and the method never goes past level 3 again.

Output

Log lines use %8ld %5d %c %d NAME[ @ loop] (SIZE bytes)[ made not entrant]: the tick, the compile id, % for OSR (else a space), and the level.

cCopy
Loading…

• status: for each method in declaration order, NAME: level L DESC, invocations I, backedges B since then, traps T[, C2 disabled]. DESC is interpreter, C1 (no profiling), C1 (limited profiling), C1 (full profiling) or C2.
• Errors:
  • method: NAME SIZE (1-65535 bytes), method X: already defined, method X: too many methods (16 max)
  • call: NAME [COUNT 1-10000000] / loop: …
  • call: unknown method X (likewise for loop and trap)
  • trap: NAME REASON
  • unknown command X

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Check the thresholds after every single invocation or back-edge, not once per command. The log tick must show exactly where each threshold was crossed.
2. Keep OSR code separate from the method's normal compiled code. OSR compiles never make the normal code not entrant.

Hidden tests cover OSR at both levels followed by a normal C2 compile, repeated traps that disable C2, traps on non-C2 code, and command errors.