Kotlin, C++ and C# make a class's methods non-overridable unless the author writes `open` or `virtual`; Java and Python make them overridable unless the author writes `final` or an equivalent. Setting the API-design argument aside, what does each default buy or cost the machinery that has to resolve the call — an ahead-of-time compiler, a JIT, and a framework that generates subclass proxies at runtime?

## What "binding" means here **Binding** is deciding which body of code a call runs. **Static (early) binding** picks it at compile time from the *declared* type of the receiver; **dynamic (late) binding** picks it at run time from the *actual* type, normally through a per-class table of function pointers (a vtable, or an interface table). Dynamic dispatch costs an indirect load and jump, but the real cost is that the optimiser cannot see the callee's body: an indirect call is an opaque wall that blocks inlining and everything inlining unlocks — constant folding, escape analysis, dead-branch removal, register allocation across the boundary. **Devirtualisation** is proving that a dynamically-dispatched call has exactly one possible target and replacing it with a direct call, usually followed by inlining. Every argument below is about who is allowed to make that proof, and when. ## Two defaults, one keyword Java, Python, Ruby and Objective-C dispatch by default; the author writes `final` (or nothing at all, in the dynamic three) to stop it. C++, C#, Kotlin and Swift-across-module-boundaries bind statically by default; the author writes `virtual` or `open` to opt in. Rust and Go sidestep the question — Rust's default is static dispatch through monomorphised generics, with `dyn Trait` as the explicit opt-in to a vtable — but the tradeoff is identical: the language decides whether the compiler is *told* the target is fixed or must *prove* it. ## What an ahead-of-time compiler gets from the promise An AOT compiler emits machine code once and can never revisit it. If a method is overridable and the compiler is compiling a library separately from its consumers, any class in any future consumer might override it, so the compiler must keep the indirect call. The keyword is therefore not a micro-optimisation hint, it is the *only* evidence available. This is why `final` measurably matters in Swift with whole-module optimisation, in Kotlin/Native, and in C++ where `final` on a class or virtual method is a documented devirtualisation aid. The exception is a **closed world**. GraalVM native-image and .NET NativeAOT analyse the entire program plus its libraries, with no dynamic class loading permitted afterwards. If only one implementation of a method is reachable in that image, the call can be bound statically even though the source left it open — and unlike a JIT, the compiler never has to plan for being wrong. Closed-world analysis substitutes for the keyword; separate compilation cannot. ## What a JIT does instead HotSpot compiles late and can recompile. It devirtualises using two independent facts. **Class hierarchy analysis (CHA)** asks whether, among the classes loaded *so far*, exactly one implements the method; if so, the call is compiled as a direct, inlined call, and the compiled method records a dependency on that assumption. **Type profiles** gathered by the interpreter say which receiver classes actually showed up at this specific call site; a site that saw one type (monomorphic) or two (bimorphic) is inlined behind a cheap class check, with a slow path for anything else. Both are undoable. When a class that breaks a recorded assumption is loaded, the JVM invalidates the dependent compiled code and **deoptimises** — execution falls back to the interpreter, mid-frame if necessary, and the method is later recompiled with a guard or a genuine virtual call. .NET's RyuJIT does the equivalent with guarded devirtualisation and, with dynamic PGO on by default from .NET 8, profile-driven type guards. The consequence is that on the JVM, `final` on a method rarely buys speed the JIT was not already getting. What *does* cost you is a genuinely **megamorphic** call site — many receiver types at one place — where no guard pays for itself, inlining is abandoned, and the wall goes back up. That is a property of the actual type distribution, not of the modifier. ## Where sealing collides with the tooling A large slice of framework behaviour — transactions, caching, lazy loading, security, test doubles — is implemented by generating a **subclass proxy** at run time that overrides the target's methods. That mechanism requires exactly what sealing forbids. Kotlin's final-by-default surface broke Spring's CGLIB proxying badly enough that the ecosystem ships the `kotlin-spring` all-open compiler plugin, which reopens classes carrying Spring annotations. In C#, dynamic-proxy libraries and EF Core's lazy-loading proxies can only intercept `virtual` members, which is why .NET APIs lean on interfaces. Swift requires `open` rather than `public` for cross-module subclassing, and adds `@objc dynamic` when a tool needs message-level interception (KVO, some instrumentation) that a vtable cannot provide. So the sealed default hands the AOT compiler a real optimisation and hands the runtime toolchain a real problem, and the ecosystem pays for it with a compiler plugin or an interface-first style. ## How to decide Ask what compiles your code. On HotSpot or CoreCLR, choose the default for API and correctness reasons and do not claim a speed win you have not measured. On an AOT target, treat `final`/`sealed`/non-virtual as performance-relevant and seal the hot paths. Either way, prefer **interface-based** extension points: interface proxies work under both defaults, and a sealed implementation class behind a published interface gives the AOT compiler its promise without breaking the frameworks.