The model
A just-in-time compiler translates code while a program runs. A runtime may begin by interpreting or compiling quickly, then use execution counters or profiling to identify frequently executed paths worth optimizing. The result can be specialized using assumptions about observed types and control flow.
A concrete walk-through
If a function repeatedly receives integers, a JIT may generate a fast integer path guarded by a type check. If later calls use another type, the guard can fail and execution falls back or deoptimizes to a less specialized representation. This lets the runtime trade compilation cost for faster repeated work.
Costs and failure cases
Warm-up behavior means short benchmarks can measure a different execution mode from long-lived production. Aggressive optimization can increase code size and compilation latency. A deoptimization is not necessarily a bug; it is a correctness-preserving response when an optimization assumption no longer holds.
Check your understanding
Design a benchmark to compare an interpreter and a JIT fairly. Explain why including startup and warm-up in one run can answer a different question than steady-state throughput.