Why architecture matters here
Idiomatic Java allocates constantly. Returning an Optional, iterating with an Iterator, boxing an int into an Integer, building a small Point to pass coordinates, concatenating strings, wrapping a value in a wrapper for an API — each creates a short-lived object on the heap. Individually these are cheap, but in a hot loop running millions of times per second they generate enormous allocation pressure. Every allocation touches the allocator, and every object created is an object the garbage collector must later trace and reclaim, so allocation rate directly drives GC frequency, pause times, and the memory bandwidth spent on the young generation.
The naive fix — rewrite the code to avoid allocation, reuse mutable objects, hand-roll object pools, pass primitives everywhere — is exactly the kind of low-level, error-prone contortion that Java exists to spare programmers. Object pools reintroduce lifetime bugs; mutable shared state reintroduces concurrency bugs; primitive-threading obscures intent. Escape analysis is the compiler's promise that you should not have to make that trade: write the clear, allocating code, and the JIT will remove the allocation wherever it can prove doing so changes nothing observable.
The reason this can be done safely is a property of the JVM: it is a managed runtime with a JIT that recompiles hot code and can deoptimize if an assumption proves wrong. The compiler does not need to be conservatively correct for all possible executions the way an ahead-of-time compiler for C must be. It can specialize on what it observes — this call site is monomorphic, this object is only read locally — apply an aggressive transform, and install a guard so that if reality diverges (a different type shows up, the object turns out to escape via a path taken at runtime) it falls back to the safe, unoptimized version. That combination of profile-guided specialization plus a deopt safety net is what makes it acceptable to outright delete allocations and locks from compiled code, and it is the same foundation that powers HotSpot's other speculative optimizations.
The architecture: every piece explained
Escape analysis classifies every allocation in the compiled scope into one of three escape states. NoEscape: the object is used only within the method and its inlined callees; nothing outside can reference it. ArgEscape: the object is passed as an argument to a method (so a callee sees it) but does not escape to the heap or another thread — it does not become globally reachable. GlobalEscape: the object is stored in a static field, an instance field of an escaping object, returned to an un-inlined caller, or otherwise made reachable beyond the current thread's control. The analysis is a connection-graph computation: the compiler tracks how references flow between objects and fields to prove the tightest state it can.
The most valuable transform, applied to NoEscape objects, is scalar replacement. Instead of allocating the object at all, the compiler dissolves it into its scalar fields and treats each as an independent local value living in a register or on the stack frame. A Point p = new Point(x, y) whose p.x and p.y are read a few times simply becomes two register values x and y; the object header, the heap slot, and the eventual GC work all vanish. This is subtly different from — and more powerful than — literally allocating the object on the stack, because once the object is scalarized its fields participate in all the compiler's normal register optimizations.
The second transform, applied where an object does not escape the thread, is lock elision (also called synchronization elimination). If a synchronized block locks an object that the analysis proves is thread-local — a classic case is a method that creates a StringBuffer or a locally-scoped collection and synchronizes on it — then no other thread can ever contend that lock, so the compiler removes the monitor enter/exit entirely. The synchronization becomes a no-op, which is why the historical performance gap between StringBuffer and StringBuilder often disappears in JIT-compiled code.
Underpinning all of it is inlining and the deopt safety net. Escape analysis is only as good as the scope it can see: a factory method that returns a new object appears to let it escape until the method is inlined into the caller, so C2 inlines aggressively first and analyzes the merged code. And every transform is speculative — installed under the assumption that certain call sites stay monomorphic and certain paths are not taken. If those assumptions break, the JVM deoptimizes back to the interpreted/unoptimized version, materializing a real heap object on the fly so semantics are preserved. Escape analysis is controlled by -XX:+DoEscapeAnalysis (on by default with C2) and its sub-optimizations -XX:+EliminateAllocations and -XX:+EliminateLocks.
It helps to distinguish scalar replacement from the 'stack allocation' people often assume the JVM does. HotSpot does not, in general, allocate a whole object on the stack and hand out a pointer to it; instead it does something stronger for NoEscape objects — it makes the object disappear as an object entirely, replacing it with its constituent scalar fields as independent SSA values that the register allocator treats like any other local. There is no header, no contiguous memory layout, no pointer; d.x and d.y are simply two numbers. This matters because a stack-allocated object would still be a real object with a header and would still force the fields to live together in memory, whereas scalar replacement lets each field be optimized, kept in a register, or even eliminated independently if unused. The consequence is that partial escapes — where an object escapes on one branch but not another — are harder for HotSpot to handle than a clean NoEscape, because scalar replacement wants the object gone on all paths; some JVM implementations add partial-escape analysis to cover those cases, but the mainline optimization is strongest when the object never escapes at all.
End-to-end flow
Trace a hot method. A pricing loop calls distance(a, b) millions of times, and distance internally does Point d = new Point(b.x - a.x, b.y - a.y); return Math.sqrt(d.x*d.x + d.y*d.y). On the interpreter and early C1 tiers, this allocates a Point per call. Once the method crosses the compilation threshold, C2 takes over. It first inlines distance into the loop body and inlines the Point constructor, so the allocation and its field reads now sit in one contiguous scope the compiler fully controls.
Escape analysis runs its connection-graph pass over that scope. The Point d is never stored in a field, never returned (only sqrt's double result leaves), and never passed to unknown code — so it is classified NoEscape. Scalar replacement fires: the compiler deletes the new Point, replacing d.x and d.y with two local values computed directly from a and b's (themselves possibly scalarized) fields. The emitted machine code for the loop contains no allocation instruction at all — the arithmetic happens in registers and the loop generates zero garbage. What looked like millions of short-lived objects becomes a tight numeric loop, and the young-generation GC that would have been triggered by that allocation simply never runs.
Now the lock case. A method builds a result string via a local StringBuffer sb (a synchronized class), appends in a loop, and returns sb.toString(). C2 inlines the append and toString paths. Escape analysis sees sb is created locally and never handed to another thread — the toString() result escapes, but sb itself does not — so it is at most thread-local. Lock elision removes the monitor operations on every append, turning the synchronized buffer into effectively an unsynchronized one for this call, and scalar replacement may further dissolve sb's bookkeeping fields. The synchronization overhead disappears without the programmer choosing StringBuilder by hand.
Finally the safety net. Suppose the loop's call target is not truly monomorphic: after the optimized code has run for a while, a subclass overriding a method involved in the scope shows up, invalidating an inlining assumption the escape analysis relied on. The JVM deoptimizes the compiled method — it discards the specialized machine code, reconstructs the state the interpreter expects (materializing any scalar-replaced object into a real heap object so its fields are consistent), and resumes execution safely. C2 will later recompile with the new profile. The aggressive removal of allocations and locks is therefore never a correctness risk; it is a bet backed by an always-available fallback.
The dependence on inlining is worth dwelling on because it is the single most common reason escape analysis silently fails to fire in real code. Consider a hot loop that calls a small factory or accessor which allocates and returns an object; in isolation, that method unambiguously lets the object escape — it returns it. Only after the callee is inlined into the loop can the compiler see that the caller immediately consumes a field and discards the object, collapsing a return-then-read into a local computation and reclassifying the allocation as NoEscape. This is why the two optimizations are inseparable: escape analysis is essentially useless without aggressive inlining to assemble a large enough scope, and inlining is limited by method size, call-site polymorphism, and the compiler's inlining budget. A megamorphic call site — one that has seen many receiver types — cannot be inlined confidently, so any allocation that would need cross-method visibility to be proven local stays on the heap. In practice, the code shapes that benefit most from escape analysis are exactly the ones that inline well: small, monomorphic, final or effectively-final methods on hot paths.