Also known as: JIT, AOT

Just-in-time (JIT) compilation translates code to native machine code while the program runs, optimizing the parts it observes executing most; ahead-of-time (AOT) compilation does all of that translation up front, before the program ever ships.¹

A JIT runs bytecode, spots a frequently-executed "hot" path, and compiles it to native code on the fly.

How it works

An AOT compiler produces a finished native binary — the approach C, Rust, and Go take. A JIT instead ships portable bytecode that a virtual machine begins interpreting; as it runs, the JIT spots frequently executed (“hot”) sections, compiles them to native machine code, and can optimize based on what it actually observes — types, branch directions, inlining opportunities. The result is often near-native steady-state speed.¹

Trade-offs

AOT gives instant startup and predictable performance, and can produce a self-contained static binary. A JIT trades that for slower startup (the engine must warm up before hot paths are optimized) and higher memory use (it holds both bytecode and generated native code). A long-running server happily pays the warm-up to gain peak throughput; a short-lived command-line tool may exit before warm-up pays off, so AOT often suits it better.¹

In practice

The JVM JIT-compiles bytecode via HotSpot, V8 powers JavaScript in Chrome and Node.js, and .NET JIT-compiles its intermediate language. The lines blur: Java is AOT-compiled to bytecode and JIT-compiled to native code, and tools like GraalVM can AOT-compile traditionally JIT’d languages for instant startup.

Sources

1. Just-in-time compilation — Wikipedia, on JIT translating hot paths to native code at run time and how it contrasts with ahead-of-time compilation. ↩ ↩² ↩³

See also

• Compiler
• Interpreter
• Bytecode
• Static binary
• Java
• JavaScript
• Go

Learn it step by step

• Compiled vs interpreted languages
• Performance vs productivity