Java calls through interfaces and overridable methods are virtual. How can a JIT compiler still inline such a call, and what must be proved or guarded for that to be legal?

## Why this is hard Most Java calls are `invokevirtual` or `invokeinterface`. The target depends on the run-time class of the receiver, and Java allows classes to be loaded at any moment, so no compiler can decide the target once and for all by looking at source. Yet without a single known target there is nothing to inline, and without inlining most other optimizations stall. Devirtualization is how a JIT escapes this. ## Route 1: prove it, then take back the proof if needed Class-hierarchy analysis (CHA) asks the runtime: among the classes currently loaded, how many override this method? If the answer is one — an extremely common situation, since most interfaces have a single implementation in a given process — the compiler emits a direct call to that body and inlines it, with no run-time check at all. This is only sound because the assumption is *revocable*. The compiled method (nmethod) records a dependency of the form "no other implementer of this method exists". Class loading consults these dependencies: when a second implementer is defined, the JVM marks every dependent nmethod as not-entrant and deoptimizes any frames currently running it, falling back to the interpreter and later recompiling with a weaker assumption. This is the same machinery that makes speculative optimization safe generally. A closely related, cheaper case is exact-type inference: if the compiler can see the allocation (`List<X> l = new ArrayList<>(); ... l.add(v);` in one compiled region), the receiver's exact class is known outright, no CHA and no guard needed. And calls that are non-virtual in the first place — `invokestatic`, private and `super` calls, constructors — never need any of this. ## Route 2: speculate on the profile, guard the speculation When several implementations exist, the compiler falls back to what the site has actually observed. While a method is interpreted or running in a profiling compiled tier, HotSpot records receiver classes per call site in that method's profile data (a small number of type slots, governed by `TypeProfileWidth`, plus a counter for "something else"). If one type dominates, C2 emits a **monomorphic guard**: load the receiver's class word, compare it to the expected class, and on match run the inlined body; on mismatch execute an uncommon trap that deoptimizes to the interpreter, updates the profile and eventually triggers recompilation. If two types dominate, it can perform **bimorphic inlining**: two checks and two inlined bodies, with a trap for the rest. Beyond that, the site is megamorphic and the compiler stops trying. ## Why the guard is worth it A guard costs a load and a compare-and-branch that predicts perfectly when the speculation holds. In exchange, the callee's body is exposed to constant folding, check elimination and escape analysis. The economics are strongly in favour of guarding, which is why HotSpot speculates aggressively rather than falling back to dispatch. ## What breaks it - A truly polymorphic hot site with many receiver types: no dominant type, no inlining. - Profile pollution: a shared helper whose inner call site is reached from many contexts records the union of all their types, so even callers that are monomorphic in reality inherit a megamorphic profile. - Late class loading that invalidates a CHA-based assumption in steady state, causing recompilation churn — usually harmless, occasionally visible in latency after a plugin or framework loads new classes. ## Design consequences Single-implementation interfaces cost nothing; abstraction is not the enemy. The enemy is many receiver types flowing through *one* hot call site. Splitting a loop per type, specializing a pipeline at construction time so each compiled path sees one class, or duplicating a hot shared helper to give it its own clean profile are the standard remedies. `final` and `sealed` help the compiler's reasoning marginally but do not rescue a site that genuinely sees many types.