When can the Go compiler turn an interface method call into a direct, inlinable call?

## Devirtualisation, defined *Devirtualisation* is replacing a call whose target is decided at run time with a call to a specific function decided at compile time. In Go that means turning a call through an interface value into a call to a named method of a named concrete type. The payoff is rarely the jump itself; it is that a direct call can be **inlined**, and once the body is inlined the compiler can propagate constants through it, eliminate bounds checks, keep values in registers and — often the biggest effect — perform real escape analysis on the arguments instead of assuming they are retained. ## Path one: static devirtualisation The compiler devirtualises when it can prove the dynamic type at the call site from the code in front of it. The classic case is local: ```go var r Resizer = boxResizer{quality: 90} return r.Resize(dst, src, 64, 64) // the compiler knows this is boxResizer.Resize ``` This matters more than the toy example suggests, because inlining feeds it. When a small constructor or wrapper is inlined into its caller, a concrete type that used to be hidden behind a function boundary can become visible at the call site, and a call that was indirect one pass earlier becomes direct. What it will *not* do is reason about the program as a whole. Even if exactly one type in your repository implements an interface, the compiler works a package at a time: another package, or a test binary, may add an implementation later. Techniques that rely on seeing every subtype in the program are not available to it. ## Path two: profile-guided devirtualisation When the build is given a representative CPU profile, the compiler gets information it cannot derive statically: which call sites are hot, and which concrete receiver types actually flow through them. If one type dominates a hot interface call site, the compiler can emit a **guarded** direct call — conceptually: ``` if the receiver's dynamic type is boxResizer { call boxResizer.Resize directly // and this can now be inlined } else { ordinary indirect call } ``` Correctness never depends on the guess. A receiver of a different type simply takes the fallback path. That is what makes the technique safe to apply from a profile that may be out of date: a stale prediction costs a comparison and a lost inline, never a wrong answer. ## What the guard buys, and what it costs The win is the inlined body on the dominant path, with all the downstream optimisation that unlocks. The costs are a type comparison per call, some code growth at the site, and a build whose output depends on an input that ages. If the mix of concrete types at that site shifts — a new implementation takes over, a feature flag flips the default — the prediction is simply wrong more often and you drift back towards the un-optimised behaviour. ## How this changes what you write It does not change much, and that is the point. You still keep interfaces where they buy substitutability, and you still keep the inner loop over concrete types where you measured that it matters. Devirtualisation is a reason not to panic about a seam that a profile shows is dominated by one implementation, not a licence to route everything through interfaces and hope. When you want to know whether it happened, the compiler's optimisation output — the same `-gcflags=-m` inlining and escape decisions you would read for any hot function — is the place to check that the callee is now being inlined at the site you care about.