Escape Analysis & Scalar Replacement

## The problem In Java, `new SomeObject()` normally allocates memory on the **heap** — a shared region of memory managed by the **garbage collector (GC)**, the subsystem that automatically reclaims memory no longer in use. Heap allocation costs CPU time, and every allocated object eventually has to be tracked and freed by the GC. Programs that create many tiny, short-lived objects (iterators, wrapper objects, temporary points/pairs, boxed numbers) can spend a surprising amount of time allocating and garbage-collecting them. ## What escape analysis is **Escape analysis** is an analysis performed by the **JIT compiler** — the part of the JVM that, at runtime, compiles frequently executed ("hot") bytecode into optimized native machine code. In HotSpot (the standard OpenJDK JVM) this is the **C2 compiler**. Escape analysis asks one question about each object a method creates: *can a reference to this object be seen anywhere outside the method that created it, or by any other thread?* If the answer is no, the object is purely local and the compiler is free to optimize it aggressively because nothing else can observe how (or whether) it exists. The word "escape" means: a reference leaks beyond the current method or current thread. ## The three escape states The analysis classifies each object into one of three states: - **NoEscape** — the object never leaves the method and is never seen by another thread. This is the best case and unlocks all the optimizations below. - **ArgEscape** — the object is passed as an argument to another method (a callee) but does not get stored anywhere globally and is not returned to the caller. It escapes the current method's scope into a callee but the compiler can still reason about it, especially if the callee is inlined. - **GlobalEscape** — the object is reachable from outside: it is returned from the method, stored into a static field or an instance field of another object, thrown as an exception, or assigned somewhere a different thread could reach. No allocation-avoiding optimization is possible. ## The optimizations it enables 1. **Scalar replacement** — the headline optimization. Instead of allocating the object at all, the compiler "explodes" it into its individual fields (its **scalars**) and keeps those values directly in CPU registers or on the **stack** (the per-method-call scratch memory that is cheap to allocate and freed automatically when the method returns). For example, a temporary `Point` with `x` and `y` becomes just two local `int` values. No object header, no heap memory, nothing for the GC to collect. 2. **Stack allocation** — a fallback where the whole object is allocated on the stack rather than the heap. (In practice HotSpot's C2 relies on scalar replacement rather than true stack allocation, but conceptually it is the same family.) 3. **Lock elision (synchronization elision)** — if an object can only ever be seen by one thread, then any `synchronized` block on it is pointless and the compiler removes the locking entirely. A classic example is using a local `StringBuffer` (whose methods are synchronized) inside one method. ## Why short-lived objects become "free" Because scalar replacement removes the allocation completely, the cost of a non-escaping temporary object collapses to roughly the cost of using a few local variables. This is why idiomatic Java that creates many small helper objects can still run fast: the JIT erases most of them. ## What defeats it Escape analysis is conservative — if it cannot *prove* an object stays local, it assumes the worst (GlobalEscape) and skips the optimization. Common defeaters: - **Returning the object** from the method. - **Storing it into a field** (instance or static) of another object. - **Passing it to a method the compiler cannot see into** (e.g. a non-inlined or virtual call it cannot devirtualize). - **Throwing it as an exception**, or putting it somewhere reachable by another thread. - The analysis is also bounded by **inlining**: escape analysis works on the inlined method body, so if a hot call is too big to inline, callee behavior becomes opaque and objects passed in tend to escape. ## Practical notes - It only happens **after JIT compilation**; interpreted code and not-yet-hot methods allocate normally. - It is enabled by default; the flag `-XX:+DoEscapeAnalysis` controls it (on by default), and `-XX:+EliminateAllocations` controls scalar replacement. - You generally should **not** hand-optimize against it; write clean code with small short-lived objects and let the JIT erase them. But know that the optimization is fragile — a single `return` or field store can disable it.