Pipelinetypical

Ahead-of-Time Compilation

Do all the work before the program starts, and inherit four consequences: the fastest possible start, an unlimited optimization budget, one artifact per target, and permanent ignorance of everything only the run knows.

The question

What do I actually get by compiling ahead of time, and what am I giving up?

Source→Lexing→Tokens→Parsing→AST→Semantics→Typed→IR→Optimize→Codegen→Machine code→Link→Execute

What the program is here

A finished artifact — machine code in an object file or executable, with a symbol table, relocations and optional debug sections — produced by a process that has exited. The question this representation exists to answer is "what should the CPU do", answered completely, before the first input has been seen. Nothing in the artifact can be revised in the light of what the run turns out to look like.

What this phase may assume or do

An ahead-of-time compiler may specialise on any fact it can establish for *every* possible execution: the declared types, the constants in the source, the set of definitions in the linked program under a closed-world assumption. It may not specialise on a fact that merely happens to hold for the runs it was shown, because there is no guard mechanism and no way back. Devirtualizing a call is legal only if no subclass that overrides the method can exist in the final program — which holds when the class is final or the whole program is known, and fails the moment a plugin can be loaded.

Key points

One decision — translate before the program starts — mechanically produces four consequences: fast start, unlimited optimization budget, a per-target build matrix, and no access to run-time facts.
The difference from a JIT is the standard of evidence, not the set of transformations: prove for all executions rather than observe and guard.
Aggressive whole-program optimization requires a closed world, and a closed world forbids reflection, dynamic loading and run-time code generation unless they are declared.
Most of the cost of the strategy lands in operations: build matrices, symbolication, image size and the inability to adapt without a redeploy.
Profile-guided optimization is the standard partial escape, carrying a recording of past runs backwards across the build boundary.

The four consequences

Ahead-of-time compilation is one decision — do the translation before the program starts — and everything else follows from it mechanically. It is worth listing the consequences separately, because teams usually adopt it for one and are surprised by the other three.

Start-up is the loader. There is no parse, no bytecode generation and no warmup. A native executable begins executing user code within milliseconds of exec, which is why the strategy dominates command-line tools and short-lived functions. See [[the-loader]].
The optimization budget is unbounded. The compiler may spend minutes on a program that will run for a year, and nobody is waiting. Inlining across modules, whole-program devirtualization and link-time optimization are all affordable here and unaffordable in a compiler running inside the process it is optimizing. See [[link-time-optimization]].
Portability is now a build matrix. The artifact encodes one instruction set, one ABI and one operating system convention. Supporting four platforms means four builds, four sets of test infrastructure and four things that can be misconfigured. See [[cross-compilation]] and [[target-triples]].
Run-time facts are unavailable, permanently. Which types actually flow through a call site, which branch is actually taken, which method is actually hot — none of it exists at build time, and there is no mechanism to revise a decision later. Everything must be proved, not observed.

What "prove, not observe" costs

typicalMainstream C++ compilers generally devirtualize under -flto when the whole program is visible and the class hierarchy is closed, and generally do not without it, because a separately compiled translation unit could always add an override. GCC additionally offers -fdevirtualize-speculatively, which emits a type check and a fallback — that is, it borrows the JIT's technique. Neither behavior is guaranteed and both vary by version.

The difference between an ahead-of-time compiler and a JIT is not the quality of the transformations, which are largely the same ones. It is the standard of evidence. A JIT may inline the one implementation it has actually seen and insert a check; if the check fails it deoptimizes and no harm is done. An ahead-of-time compiler has no check to insert and nowhere to fall back to, so it must establish that no other implementation is possible.

That standard is why the same transformation is routine in one shape and requires a whole-program analysis in the other, and it is the sharpest illustration in the domain of [[optimization-legality]] — the transformation did not change, only what could be established about it.

Devirtualizing a call through an interface

Before

Shape* s = get_shape();
double a = s->area();   // indirect call through the vtable

After

double a = Circle_area(static_cast<Circle*>(s));  // direct call, then inlinable

Legal only when

Only if the compiler can establish that Circle is the only type in the final program that can be the dynamic type of s here. That holds when the class or the method is final, when the whole program is visible and no other override exists, or when the type is provably constructed at a known site and never escapes. Once the call is direct, inlining it becomes possible and the real gain follows from that rather than from the call itself.

Illegal when

If any additional translation unit, shared library or plugin loaded at run time may define another Shape subclass that overrides area. Then the direct call reaches the wrong implementation and the program silently computes the wrong answer — no crash, no diagnostic. This is exactly why a JIT can do the same transformation on weaker evidence: it guards on the receiver type and deoptimizes on a miss. See [[devirtualization]], [[guards]] and [[whole-program-optimization]].

The dynamic features that stop working

implementationGraalVM native-image requires explicit reflection and resource configuration and performs its own points-to analysis over the closed world; .NET Native AOT makes a similar closed-world assumption with a different configuration mechanism and different unsupported features. The shape of the restriction is common to the strategy; the exact list of what breaks is per-toolchain and per-version, and must be read from that toolchain's documentation rather than assumed.

The closed-world assumption that makes aggressive ahead-of-time optimization possible is also a restriction on what the program may do, and this is where migrations go wrong. If everything reachable must be known at build time, then anything that constructs reachability at run time has to be declared, restricted, or given up.

GraalVM native-image is the clearest case because it states the assumption explicitly. Reflection, dynamic proxies, service loading and resource lookups by computed name all need configuration files listing what will be reached, or they fail at run time with a class-not-found error on a code path that worked for years under the JVM. The failure is not a bug in the tool; it is the closed-world assumption arriving in person.

The same tension appears in every language with dynamic loading. A C++ program that dlopens a plugin cannot have been whole-program optimized across that boundary. A Java program that generates classes at run time cannot be fully ahead-of-time compiled. A Python program calling eval needs a compiler resident regardless of what else was done ahead of time.

Deployment is where the bill arrives

The engineering consequences of ahead-of-time compilation are mostly operational, and they are usually discovered after the technical decision has been made.

A native artifact is per-target, so the release pipeline grows a matrix. Crash reports arrive as addresses, so a symbol server and a symbolication step become part of the infrastructure rather than a debugging nicety — [[symbolication]]. Binary size becomes a container image size, which becomes a pull latency on every cold node. And because the compiler is not present at run time, the only way to change behavior is to rebuild and redeploy, which is a feature when you want reproducibility and a constraint when you want a feature flag to change a code path's cost.

Against that: a single self-contained executable with no runtime dependency is a genuinely simpler operational object than a program that needs a matching interpreter version installed on every host, and the entire distribution story for Go and Rust command-line tools rests on it.

What the strategy costs and buys, in operations rather than in benchmarks

Concern	Ahead of time	Translation at run time
Release artifacts	One per target triple, plus a build matrix to produce them	One, plus a runtime that must be present and version-matched on every host
Cold starttypical	Loader time. Milliseconds	Parse plus interpretation plus warmup before steady state
Crash reports	Addresses. Requires stored symbols and a symbolication pipeline	Named stack traces produced by the runtime itself
Memory footprint	Code plus data, with no compiler and no generated code resident	Additionally the compiler, its metadata and the machine code it produced
Changing behavior in production	Rebuild and redeploy. Nothing else is possible	Also rebuild and redeploy, but the runtime can adapt to load without one
Reproducibility	Achievable and checkable — the artifact is the whole story. See `[[reproducible-compilation]]`	Harder: identical inputs can produce different machine code run to run

How it works

The steps, in the order the compiler takes them.

The whole program, or one translation unit at a time, is lexed, parsed, checked, lowered to IR and optimized before any execution.
Optimizations that need to see across module boundaries are deferred to link time, where the IR of every unit is available at once.
Instruction selection, scheduling and register allocation commit the program to one instruction set and one ABI.
The assembler and linker produce an artifact with symbols, relocations and optional debug and unwinding sections.
At run time the loader maps the artifact, applies relocations, binds any dynamic symbols and jumps to the entry point; no translation occurs after this.

How it breaks

What the engineer observes when it goes wrong — not what goes wrong internally.

A service migrated to a native-image build starts in fifteen milliseconds and then throws a class-not-found error weeks later, on a reflective code path that no test exercised.
A crash in production produces a stack of hexadecimal addresses, and the symbols for that exact build were not archived, so the report is unusable.
A binary compiled with a newer instruction-set baseline crashes with an illegal-instruction fault on older hardware in the fleet, and only on the machines that happen to be older.
A build takes forty minutes because link-time optimization was enabled for a small measured gain, and developer iteration time quietly becomes the largest cost in the project.
A plugin loaded at run time behaves differently from the same code linked statically, because devirtualization and inlining were applied across a boundary the plugin later crossed.

When it helps

Short-lived processes: command-line tools, serverless functions and anything invoked per request, where warmup is a cost paid on every invocation and never amortised.
Distribution to machines you do not control, where a single self-contained artifact with no runtime dependency removes an entire class of support problem.
Workloads with a hard, predictable shape where the compiler can prove what a profiler would have observed anyway.
Anywhere reproducibility matters: an artifact produced entirely at build time can be byte-for-byte verified, which a JIT-produced one cannot.

When it hurts

Long-lived processes with highly polymorphic hot paths, where a JIT's observed-type specialisation is worth more than anything a static analysis will prove.
Programs whose structure is genuinely dynamic — plugin hosts, notebook environments, anything with eval — where the closed-world assumption is not merely inconvenient but false.
Teams whose iteration speed matters more than their steady-state performance, which is most teams, most of the time, and is why debug builds exist as a separate strategy. See [[debug-vs-release]].

What it costs

Every one of these is paid by something.

An unlimited optimization budget buys cross-module inlining and whole-program analysis, and costs build wall time directly — link-time optimization routinely multiplies link time several-fold — plus the developer iteration time that build wall time consumes.
A self-contained native artifact buys deployment simplicity and start-up latency, and costs a build per target triple, an archived symbol store per build, and a binary size that becomes an image-pull cost on every cold node.
A closed-world assumption buys devirtualization, dead-code elimination across the whole program and a smaller binary, and costs reflection, dynamic class loading and plugin architectures — features that must now be declared in configuration or abandoned.
Compiling before the run buys predictability, and costs every optimization that depends on knowing which types and branches actually occurred. Profile-guided optimization recovers part of it and pays with a profile that must be collected, stored, kept representative and invalidated when the workload changes. See [[pgo-tradeoffs]].

What else you could do

What a different compiler or language does instead, and when that is better.

A bytecode VM with a JIT, which trades start-up and predictability for specialisation on real data and for portability of a single artifact — [[jit-compilation]].
Tiered ahead-of-time compilation: ship a fast-compiled baseline and a separately optimized build of the hot modules, which several game engines do to keep iteration times survivable.
Ahead-of-time compilation on the target machine at install time, which is what Android's installer-time compilation and .NET's crossgen do — build-time strategy, target-specific artifact, no build matrix for the developer.
WebAssembly as the artifact: portable like bytecode, validated, sandboxed, and compiled by the host engine either ahead of execution or as it streams — [[wasm-vs-native]].

See it for yourself

The flag, dump or tool that shows you this directly.

What was actually emitted: objdump -d ./program or otool -tv ./program, and nm --size-sort ./program to see where the bytes went.
Whether link-time optimization did anything: build with and without -flto, then diff the disassembly of a function you expect to be inlined across a module boundary.
Whether a call was devirtualized: clang -O2 -Rpass=inline -Rpass-missed=inline reports each decision and, more usefully, each one it declined and why.
What the artifact still needs at run time: ldd ./program on Linux, otool -L on macOS. An empty answer is the whole promise of static linking.
Start-up cost directly: hyperfine ./program against the equivalent under a run-time strategy. It is the one number in this lesson that never disappoints.

Plausible wrong readings

Stated the way a confident engineer states them.

"Ahead-of-time compilation is always faster." It always starts faster. Steady-state throughput on polymorphic code is a genuine contest, and speculative specialisation wins some of it outright.
"Native means no runtime." Go and Rust binaries contain runtime support — schedulers, collectors, unwinders — statically linked in. Native compilation removes the *translator*, not the runtime.
"Link-time optimization is free performance." It is a large increase in link time and memory, sometimes for single-digit percentage gains, and it must be measured on your program rather than assumed.
"If it compiled, it will run." It will run on this target triple, with this instruction-set baseline, against these library versions. Each of those is a way for a successful build to produce a binary that faults on someone else's machine.

Misconceptions

The claim, and what is actually true.

Ahead-of-time compilation means the compiler sees the whole program.

By default it sees one translation unit at a time and knows nothing about the others. Whole-program visibility requires link-time optimization or an explicit whole-program mode, and both cost build time to obtain.

A JIT can do anything an AOT compiler can, just later.

The reverse is closer to true for time-bounded transformations: a JIT cannot afford an analysis that takes thirty seconds, because the program is waiting. Their advantages come from different places entirely.

Static linking makes the program independent of the machine.

It removes the library dependency. The instruction-set baseline, the system call interface and the kernel version are still dependencies, and each has produced its own class of "works on my machine".

Go deeper

The same idea at increasing depth. Stop wherever it stops being useful.

overview

Do the translation before the program runs and you get the fastest possible start and as much optimization as you are willing to wait for. In exchange you build one artifact per platform, you can only optimize things you can prove rather than things you have seen, and changing anything means a rebuild.

practical

Turn optimization on and measure; then turn link-time optimization on and measure again, including the build time, because the second measurement often does not justify itself. Archive the symbols for every build you ship, before you need them. Pin an instruction-set baseline deliberately rather than by default. And if the program uses reflection or loads code at run time, find out now whether the aggressive modes you want are compatible with that, because the answer arrives in production otherwise.

advanced

The strategy's real constraint is epistemic rather than technical: every decision must be justified by something true of all executions. That is why the interesting engineering in this space is all about manufacturing evidence that would otherwise not exist — profile-guided optimization imports observations from past runs, link-time optimization manufactures whole-program visibility, closed-world assumptions manufacture a finite class hierarchy, and constexpr and comptime manufacture known values by running part of the program during the build. Each of them is the same move, and each is limited by the same thing: the evidence has to remain true, and nothing at run time is checking that it did.

How much this depends on

Nothing in this domain is true of every compiler. These say how much.

typicalClaims here about devirtualization, cross-module inlining and what -flto enables describe mainstream C and C++ toolchains at present. Whether any specific call is devirtualized depends on the version, the optimization level and the visibility of the class hierarchy, and is not guaranteed by any of them.

implementationGraalVM native-image and .NET Native AOT both impose a closed world and both have their own list of unsupported dynamic features and their own configuration format. The list changes between releases in the direction of supporting more, so a migration blocked two years ago may not be blocked now.

targetAn ahead-of-time artifact commits to an instruction-set baseline as well as an architecture. A binary built with AVX-512 enabled faults on hardware without it; the same source built for a conservative baseline runs everywhere and leaves performance on the table. This is a target decision, not a compiler one — see [[target-triples]].

If you were asked this in an interview

What can an ahead-of-time compiler not do that a JIT can, and why is it a difference of evidence rather than of capability?
Under what conditions may a compiler turn a virtual call into a direct one, and what happens if it does so wrongly?
Your team wants native-image builds for cold start. What do you check before agreeing?

Connections

Computer Architectureinstruction-set-architecture simd branch-prediction

Performancejit-and-warmup benchmarking

Securitysupply-chain-security

Cloudstartup-time-and-cold-start serverless-tradeoffs image-size container-images

OS & Networkingprogram-vs-process memory-mapping

Domains that do not exist yet

DevOps / Production Engineering — Build matrices, artifact stores, symbol servers and reproducible builds as pipeline concerns
Most of what ahead-of-time compilation costs is paid by the release pipeline rather than by the compiler. The compiler-side half — hermetic compilation and deterministic output — is [[hermetic-compilation]] and [[reproducible-compilation]] here; running the pipeline is theirs.