JIT compilation: compile only the hot code, at run time

What it is. JIT is Just-In-Time compilation: the runtime compiles hot bytecode into machine code while the program runs. Its neighbours are interpretation (translate line by line, fast to start, slow to run) and AOT, Ahead-Of-Time compilation (compile everything before running, fast to run, blind to run-time information).

Why it exists. Most time goes to a small set of hot spots, so interpreting them is slow. But compiling everything ahead of time wastes work on code that runs once, and it cannot see run-time facts such as actual types and branch directions. So: interpret first, profile as you go, compile only what turns hot.

Tiered compilation (HotSpot). Level 0 is interpretation; levels 1–3 use C1, the Client Compiler (fast to compile, few optimizations); level 4 uses C2, the Server Compiler (slower to compile, heavier optimizations), or Graal through JVMCI in its place. Counters (method calls plus loop back-edges) trigger upgrades; broken assumptions trigger deoptimization back down.

Mechanisms, named only. Profiling records types, branches and call targets. Speculative optimization assumes a fact, guards it with a check, and deoptimizes when the assumption breaks. Inlining removes virtual-call cost so further optimization can follow. OSR, On-Stack Replacement, swaps a running loop's frame to compiled code mid-loop. Escape analysis with scalar replacement keeps non-escaping objects off the heap; Graal's partial escape analysis is more aggressive than C2's.

Costs. Warm-up (slow at start, fast once hot), compiler CPU, CodeCache space for compiled code, and deoptimization storms when assumptions keep breaking. Long-lived services benefit; short-lived command-line programs usually do not.