Why can a code path that never ran during warmup be dramatically slow the first few times it executes, even though the method containing it has been JIT-compiled for a long time?

## What the profile actually records for branches The interpreter and the profiling compilation tier count both directions of every conditional. When the optimizing compiler runs, a branch can be: - **balanced** — compile both sides normally; - **strongly biased** — compile both, but lay out the hot side to fall through and predict accordingly; - **never taken (count zero)** — treat as unreachable and emit an **uncommon trap** in its place. The third case is the interesting one. Replacing an entire branch with a trap is not just skipping work: it removes a control-flow merge, which lets the compiler keep values in registers across the region, propagate constants and types that the merge would have destroyed, avoid spilling, and reduce code size (important for the instruction cache and for further inlining decisions). Deleting the cold half is often what makes the hot half fast. ## What happens on first execution of the cold path 1. Control reaches the trap stub with reason `unreached` (never compiled) or `unstable_if` (the profile said this side was dead). 2. The runtime deoptimizes: the compiled frame is expanded into interpreter frame(s) with locals and expression stack restored, and execution continues in the interpreter at that exact bytecode index. 3. The compiled nmethod is normally made **not entrant** and the method reprofiles. 4. After enough invocations, the method is recompiled — now with a real branch, because the counter is no longer zero. Between steps 2 and 4 the method runs interpreted or at a lower tier. For a method that was hot, that can be a 10–50× slowdown for the affected calls, plus the compilation work itself competing for CPU. ## The other members of the same family Branch pruning is the clearest case, but the pattern repeats wherever the profile encodes "never seen": - **Implicit null checks.** If a dereference has never seen null, the compiler omits the test entirely and relies on the hardware fault plus a signal handler; the first null converts a would-be `NullPointerException` path into a `null_check` deopt. - **Casts and `instanceof`.** A never-failing cast compiles without the slow path; the first failure traps. - **Exception paths.** Handlers whose bytecodes have never executed are prime candidates for pruning, so the first thrown exception in a long-running service is disproportionately expensive — the throw itself, stack-trace capture, *and* a deopt plus recompile. - **Array store checks, division by zero, class initialization checks** on classes not yet initialized at compile time. ## Why it shows up as a production symptom Typical shapes: - A service is fine for hours; the first downstream timeout produces a latency spike far larger than the timeout budget suggests, because the error path deoptimizes several hot methods at once. - A code path guarded by a rarely-true condition — month-end, leap day, a feature flag, an unusual currency — runs slowly on exactly the day it matters. - A canary deploy that shifts traffic mix makes previously-cold branches warm, producing a burst of deopts and recompiles that looks like a memory or GC problem but is compilation. `-XX:+PrintCompilation` shows `made not entrant` clustered at the moment of the event; JFR's `jdk.Deoptimization` events name the method, bytecode index and reason (`unstable_if`, `unreached`, `null_check`) directly, which is the quickest confirmation. ## What to do about it - **Warm the paths you care about.** If tail latency on error handling matters, exercise the error paths during warmup, not just the happy path. The same applies to alternate types at polymorphic sites. - **Don't use exceptions for control flow** — beyond the direct cost, every rare-path throw risks a deopt. - **Expect one-time costs and measure steady state separately** from first-occurrence cost; conflating them makes a healthy system look pathological. - **Do not attempt to disable speculation globally.** Turning off branch pruning or trap-based optimization would slow the hot path everywhere to protect a rare one; the correct lever is warmup coverage, and only in the rarest cases per-method compiler directives. The underlying bargain is worth stating plainly: the JVM buys hot-path speed by refusing to compile what has not happened, and pays for it with a one-time cliff when the unexpected finally happens.