JIT & Adaptive Optimization

The JVM first interprets bytecode while counting execution. Each method has counters for how often it is called and how often its loops iterate; when a counter crosses a threshold the JVM compiles that method to optimized native code, so hot paths speed up after warm-up.

C1 compiles fast and optimizes lightly, so code becomes native quickly with modest peak speed. C2 optimizes aggressively and compiles slowly, giving the best steady-state throughput. A single JVM uses both: C1 for quick warmup and profiling, C2 for the hottest methods.

The JIT compiles using the profile gathered so far — e.g. only one receiver type seen, this branch never taken — and replaces the unproven path with an uncommon trap. If the assumption breaks, the trap fires, the runtime deoptimizes that frame back to the interpreter at the same bytecode, and the method is later recompiled without the failed assumption.

An invocation counter (incremented on method entry) and a back-edge counter (incremented on every backward branch, i.e. loop iteration). Invocations alone miss long-running loops in rarely called methods. Crossing a threshold files an asynchronous compilation request; back-edge overflow requests on-stack replacement.

OSR compiles a method's long-running loop and transfers the currently executing invocation into the compiled code mid-flight, instead of waiting for the next call. Without it, a method entered once that loops for minutes would stay interpreted for its whole run.

Inlining replaces a call with a copy of the callee's body inside the caller. Removing call overhead is the small win; the real win is that both bodies become one compilation unit, so constant folding, null and bounds-check removal, escape analysis and loop optimizations can work across the boundary that disappeared.

Two routes. Proof: class-hierarchy analysis shows only one loaded implementation, so the compiler emits a direct inlined call and records a dependency — loading a second implementation invalidates that compiled code. Speculation: the receiver-type profile shows a dominant type, so the compiler emits a class check, inlines behind it, and traps on mismatch.

Constant folding evaluates expressions whose operands are already known at compile time. Constant propagation substitutes those known values into later uses. Dead-code elimination deletes computations nobody reads and branches that can never be taken. Each pass exposes fresh opportunities for the others.

In the interpreter the getter really is a call. Once the code is hot and JIT-compiled, a tiny accessor is inlined and the call disappears, leaving just the field load. Caveats: it only applies after warm-up, and only if the JIT can pin the call to one target.

It proves the whole loop is in range once. The compiler hoists a single guard — the index starts at or above zero and the highest index is below the array length — before the loop, then compiles the loop body with no per-element check. If the guard fails, control goes to a slow path that runs checked code and throws at the right iteration.

Three families of limits: callee size (tiny methods almost always, small ones if the site is hot, big ones never), call-site hotness from the collected invocation profile, and inlining depth plus total expansion budget. On top of that, the target must be statically bindable and compilable.

Loop-invariant code motion hoists a computation whose inputs never change inside the loop to a single evaluation before the loop. It is blocked when an input might change per iteration: a write inside the loop, an unanalysable call, possible aliasing, acquire semantics on a volatile read, or an operation whose exception or side effect must stay inside the loop.

Level 0 is the interpreter. Levels 1-3 are the fast compiler at different instrumentation settings: 3 is fully profiled, 2 is lightly counted, 1 is fully optimized with no profiling. Level 4 is the optimizing compiler. The usual path is 0 to 3 to 4.

The compiler recorded a dependency on "only one implementation exists". Loading a second one violates it, so during class loading the JVM invalidates the compiled code: it is made not entrant, frames on the stack are deoptimized, and the method is recompiled with a real virtual call or a type-guarded inline.

The compiler saw the branch profile say "never taken" and did not compile that path at all — it put an uncommon trap there. The first execution hits the trap, deoptimizes the frame to the interpreter, reprofiles, and waits for a recompilation that now includes the path.

Back-edge counter overflows at a loop bytecode index; a compile task keyed to (method, bci) produces an OSR nmethod whose entry expects the interpreter's live locals and stack. At the next back-edge the runtime copies that state into an OSR buffer, builds a compiled frame from it, and jumps to the OSR entry; the interpreted frame is discarded.

With many receiver types the inline cache gives up and the call becomes a table dispatch — a virtual-table index, or a slower interface-table search for interface calls. Nothing is inlined, so all downstream optimization is lost, and the indirect branch mispredicts. Fix by restoring one type per hot call site.

Both numbers can be correct. A microbenchmark measures an isolated operation under an artificially uniform profile; production runs it inside a mix where it may be a tiny share of total time, share call sites with other implementations, and be bounded by memory or I/O. Check the operation's share of production time first, then re-measure at the level you actually care about.

Use -XX:+PrintCompilation to see which methods were compiled, at which tier, and which were made not-entrant (deoptimized). Add -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining to see which callees were inlined or why they were refused. Confirm the method under test reaches the top tier and its hot callee is inlined.

C2 splits the iteration space into pre-loop, main loop and post-loop. The main loop is the unrolled one: its trip count is a multiple of the unroll factor, its bounds checks are gone, and the superword pass fuses its copies into SIMD instructions. Strip mining wraps it so safepoints still get polled.

Compiled code carries debug metadata mapping each trap or safepoint to a chain of virtual frames — method, bytecode index, and where every local and stack value physically lives. Deoptimization reads it, rebuilds one interpreter frame per inlined method, rematerializes scalar-replaced objects and re-locks eliminated locks, then resumes interpreting.

Match the compiler policy to process lifetime. Long-lived processes keep full tiering and get traffic-shaped warmup before receiving load. Short-lived ones stop at the fast compiler tier and lean on class-data sharing or cached profiles, because they will never repay optimizing-compiler cost.

Confirm with evidence: JFR deoptimization events or -XX:+PrintCompilation "made not entrant" lines correlated with the dips, grouped by method, bytecode index and reason. Then treat the reason — megamorphic or unstable call sites, exceptions as control flow, late class loading — rather than tuning trap limits. Rule out code-cache exhaustion, which looks identical.

An OSR entry fixes the program state at a loop head mid-flight, so the compiler has less freedom: limited loop peeling and unrolling, values pinned to the entry contract, and no profile for the pre-loop code. Structuring the hot work as a method called many times reaches the ordinary compilation path instead.