A hot Java call site dispatches on many different receiver classes. What does HotSpot do at such a megamorphic site, why is it much slower than a site that sees one class, and what can you change?

## Inline caches and their three states A call site in HotSpot is not a fixed instruction sequence; it is patched as the runtime learns about it. - **Unlinked** — not yet executed; the first call resolves it. - **Monomorphic** — one receiver class seen. The site holds a check against that class and a direct jump to its compiled entry. In optimized code the compiler usually goes further and inlines the body behind the check. This is the fast case and, in most programs, the overwhelmingly common one. - **Bimorphic** — the profile shows two dominant classes. C2 can emit two class checks and inline both bodies, with an uncommon trap for anything else. - **Megamorphic** — many classes have flowed through. Caching one or two targets is now counterproductive (each miss costs a patch or a trap), so the site is switched to a general dispatch. ## What megamorphic dispatch actually does For `invokevirtual`, the receiver's class holds a virtual method table; the compiler knows the slot index, so dispatch is: load class word, load the vtable slot, indirect call. For `invokeinterface` it is more work: interface methods do not have a fixed vtable index across unrelated classes, so the receiver's class carries an interface method table (itable) that must first be searched for the right interface, then indexed. HotSpot mitigates this but interface megamorphic dispatch remains the more expensive of the two. ## Why the slowdown is bigger than the dispatch cost Count only the instructions and megamorphic dispatch looks cheap — a couple of loads and an indirect jump. Two effects multiply it: 1. **Branch misprediction.** An indirect branch that alternates among many targets defeats the branch-target predictor; each mispredict costs a pipeline flush, easily tens of cycles. 2. **Lost inlining, which is the dominant term.** The callee body stays opaque. Arguments must be assumed to escape, so allocations that would have been scalar-replaced are materialised; caller constants cannot fold into callee branches; null and bounds checks cannot be removed; the loop cannot be unrolled or vectorized through the call. The call site becomes an optimization wall in the middle of a hot loop. ## The usual root cause: profile pollution Megamorphism is frequently *not* inherent to the algorithm. A generic helper — a mapper, a validator, a `forEach` body, a logging façade — is invoked from dozens of contexts. Its own internal call site records the union of every context's receiver types, so a caller that only ever passes one type still inherits a hopeless profile. Lambdas and method references make this easy to hit because each lambda body is a distinct class flowing through the same functional-interface call site. ## What to change - **Specialize the hot path.** Choose the implementation once, outside the loop, and run a loop per type. Each compiled loop then sees one class. - **Duplicate the shared helper** on the hot path so it gets its own clean profile; the code duplication is deliberate and should be commented as such. - **Hoist dispatch out of the inner loop** — decide per batch, not per element. - **Reduce the number of implementations reaching that site** at all: merge implementations, or route different kinds through different code paths higher up. - Do **not** expect `final`, `sealed`, or flag tuning to help; they do not change how many classes reach the site. ## Confirming rather than guessing `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` will report the site as not statically bindable; `-XX:+LogCompilation` gives per-site profile data showing the receiver-type spread. A profiler that attributes time to an indirect call inside a hot loop, with no inlined children, is the same signal seen from the outside.