the interpreter and the JIT

the picture

you know how java is "slow to start, fast once it's going"? that's this chapter. it's not the JVM being lazy: it's deliberately waiting to see what your code does before it spends effort optimizing it.

think of learning a commute in a new city. the first week you follow the map turn by turn (the interpreter). after a few trips you know the route, and you start noticing things: this light is always red, that road is always empty at 9 (C1, with profiling). a month in, you take shortcuts based on everything you noticed (C2). and if one day a road you counted on is closed, you pull the map back out (deoptimization).

watch a method warm up

digitSum adds up the digits of a number. it's called in batches of 100, and every batch is timed. this is a real run on jdk 25: scrub through it, or warm it up.

static int digitSum(int n) {
    int sum = 0;
    while (n > 0) {
        sum += n % 10;
        n /= 10;
    }
    return sum;
}

two things that surprise people. first, compilation doesn't pause your program: the method is queued, a compiler thread works on it in the background, and the interpreter keeps running the old way until the new code is installed (that's the gap between 256 and 900 calls). second, the curve has two steps, not one. the first is the jump from bytecode to machine code. the second is C2 doing actual optimization with what tier 3 learned.

the five tiers

the usual path is 0 → 3 → 4. the thresholds are plain JVM flags (java -XX:+PrintFlagsFinal -version, jdk 25):

the thresholds also scale with how busy the compiler queues are, so "200" is a starting point, not a promise. that's why the logged run queued digitSum at 256: the first check after 200.

how much does each tier actually buy? same loop, same method, forcing the JVM to stop at each tier with -XX:TieredStopAtLevel (or -Xint for interpreter only):

tier 3 being twice as slow as tier 1 is the whole design in one number. profiling is expensive, so the JVM only does it for a while, only on code that's warm, and only so C2 can make bets that beat C1 by a wide margin.

reading -XX:+PrintCompilation

the JVM will tell you every compilation as it happens. here's a program with a hot method and a long loop in main:

public class Hot {
    static int digitSum(int n) {
        int sum = 0;
        while (n > 0) {
            sum += n % 10;
            n /= 10;
        }
        return sum;
    }
 
    public static void main(String[] args) {
        long total = 0;
        for (int i = 0; i < 1_000_000; i++) {
            total += digitSum(i);
        }
        System.out.println(total);
    }
}

14    9       3       Hot::digitSum (23 bytes)
14   10       4       Hot::digitSum (23 bytes)
14    9       3       Hot::digitSum (23 bytes)   made not entrant: not used
15   11 %     3       Hot::main @ 4 (32 bytes)
15   12       3       Hot::main (32 bytes)
15   13 %     4       Hot::digitSum @ 2 (23 bytes)
15   11 %     3       Hot::main @ 4 (32 bytes)   made not entrant: OSR invalidation back branch
15   14 %     3       Hot::main @ 4 (32 bytes)
15   15 %     4       Hot::main @ 4 (32 bytes)
16   14 %     3       Hot::main @ 4 (32 bytes)   made not entrant: OSR invalidation of lower level
19   15 %     4       Hot::main @ 4 (32 bytes)   made not entrant: uncommon trap
27000000

the columns, left to right:

14

milliseconds since the JVM started. the whole climb happened in about 5 ms.

9

the compile id. the same id appears again when that compiled version is thrown away.

%

flags. % is an OSR compile, s synchronized, ! has exception handlers, n a native wrapper, b blocking.

3

the tier.

@ 4

for OSR: the bytecode index of the loop the compiled code is entered at.

(23 bytes)

size of the method's bytecode, not of the machine code.

made not entrant

this version can't be entered anymore. the reason follows: replaced by a better one, or an assumption broke.

on-stack replacement

look at main in that log. it's called exactly once, so its invocation counter never gets past 1. yet it got compiled, four times. that's on-stack replacement (OSR): the back-edge counter of its loop crossed the threshold while main was still inside the loop, so the JVM compiled a special version of main that starts at the loop (bytecode 4, the iload_3 that goto 4 jumps back to), copied the live locals out of the interpreter frame, and jumped into compiled code mid-loop.

 0: lconst_0
 1: lstore_1
 2: iconst_0
 3: istore_3
 4: iload_3
 5: ldc           #7     // int 1000000
 7: if_icmpge     24
10: lload_1
11: iload_3
12: invokestatic  #8     // Method digitSum:(I)I
15: i2l
16: ladd
17: lstore_1
18: iinc          3, 1
21: goto          4

the last line of the log is the next chapter in miniature. the C2 OSR version of main was built from a profile in which the loop never ended, so C2 didn't bother compiling the code after it. when i finally hit 1,000,000, execution reached that missing path, hit an uncommon trap, and the JVM threw the compiled code away and finished main in the interpreter. it printed 27000000 anyway. more on that in JIT optimizations.