Why does a Java application compiled ahead of time into a native binary usually reach lower peak throughput than the same application on a warmed-up JVM, and what narrows that gap?

## The information asymmetry Optimizing compilers make decisions that are only good if certain facts hold. Inlining is worth it if the callee is small and actually called often. Devirtualizing an interface call into a direct call is worth it if one implementation dominates. Skipping a bounds check is valid if the index is provably in range. Laying out code so the hot path falls through is worth it if you know which path is hot. A JVM's optimizing compiler runs after the program has been executing, and it has counters: per-branch taken and not-taken counts, per-call-site observed receiver types, per-loop trip counts, whether a given exception path ever executed, whether a null was ever seen. It optimizes against those facts. A build-time compiler for a native binary has the source and the whole reachable program, but not one bit of runtime behaviour. It can prove things (this call has exactly one possible implementation in the closed world) but it cannot measure things. ## Why the fallback matters as much as the profile The subtler half of the advantage is deoptimization. A JVM can compile code that is only correct under an assumption — for example that a call site only ever sees one receiver class, or that a class is never subclassed — provided it inserts a check and can bail out. When the assumption breaks, the frame is converted back to interpreter state and execution continues correctly, then the method is recompiled without the invalid assumption. A native binary has no interpreter and no compiler, so there is nothing to fall back to. Every optimization must be unconditionally valid or guarded by a check that is always paid. This makes speculative optimization structurally unavailable rather than merely uninformed, which is why simply feeding a profile in does not make the two models equivalent. ## The concrete gaps - **Call sites** stay indirect where a JVM would inline the single hot receiver and guard it. - **Cold code** — error handling, rarely-taken branches — is compiled and laid out as ordinary code rather than being pruned or moved out of the hot instruction stream. - **Inlining budget** is spent on heuristics rather than on the calls that actually dominate. - **Class-hierarchy assumptions** are safer in a closed world (the whole hierarchy is known) which does claw some of this back — a genuinely single-implementation interface can be devirtualized with certainty at build time. - **Garbage collection** in the image may be a simpler collector than a fully-tuned HotSpot collector, which affects sustained throughput independently of code quality. ## Profile-guided optimization The standard remedy is to give the build-time compiler the missing measurements. The flow is: build an instrumented binary, run it against a workload that resembles production, collect the recorded profile, then build the final binary with that profile. The compiler then places branches, chooses inlining, and specializes code using real frequencies. Reported gains commonly recover a large share of the difference to a warmed JVM on throughput-oriented benchmarks. Its limits should be stated honestly. It adds a two-stage build with a workload run in the middle, which complicates continuous delivery. The profile is only as good as the workload used, and a profile taken from an unrepresentative load can misdirect optimization. And because there is still no deoptimization, the binary cannot adapt when production traffic changes shape — a JVM would simply reprofile and recompile. ## The judgment to express If the process lives long enough to warm up and throughput is the objective, the JVM's adaptive model has a structural advantage and you should expect to keep it. If processes are short-lived, numerous, or memory-constrained, the throughput ceiling is largely irrelevant because the JVM would rarely reach it, and native compilation wins on the metrics that actually bind. Profile-guided optimization is the tool for the middle ground: a long-running service that nevertheless needs fast startup and small footprint.