Why is escape analysis fragile? Identify concrete code patterns that defeat it, and how inlining limits affect it.

## Why 'fragile' is the right word **Escape analysis** must be *sound*: it may only optimize away an object when it can **prove** that doing so changes nothing observable. Proof is hard, so the analysis is **conservative** — whenever it cannot establish that an object stays local, it assumes the worst (**GlobalEscape**) and applies no optimization. Combined with the fact that it works over a method body *plus whatever got inlined into it*, this makes the optimization easy to disable by accident. The object is 'free' only while a chain of conditions all hold. ## Direct defeaters — patterns that explicitly leak the reference These make the object visible outside the creating method, so it must really exist: - **Returning it:** `return new Foo();` — the caller now holds the reference. GlobalEscape. - **Storing it in a field:** `this.cache = new Foo();` or `STATIC = new Foo();` — reachable through another object / globally. - **Throwing it:** `throw new MyException();` — exception objects are published up the stack. - **Publishing to another thread / shared structure:** putting it in a static, a shared map, or handing it to an executor/thread — now another thread can observe it. - **Putting it into an array/collection that escapes:** the container carries the reference out. These are the 'obvious' ones the contract mentions (storing to fields, returning the object). ## Indirect defeaters — the inlining and dispatch story (the senior/principal nuance) Escape analysis in C2 reasons about the **inlined** scope. A call to another method is a boundary: if the JIT cannot see the callee's body, it must assume the callee could store or return the argument, so any object passed in **ArgEscapes and is treated as escaping**. Whether the JIT can see the body depends on **inlining**, which is bounded: - **Method too large:** inlining has size/frequency budgets (e.g. controlled by flags like `MaxInlineSize`/`FreqInlineSize`). A hot path calling a method that exceeds the budget won't inline it, leaving the callee opaque — objects passed in escape. - **Virtual dispatch that can't be devirtualized:** a call through an interface/overridable method must be resolved to a concrete target to inline. If the call site is **monomorphic** (one type) the JIT can usually devirtualize and inline; if it is **bimorphic/megamorphic** (sees many concrete types), it often cannot, so the callee stays opaque and arguments escape. - **Bytecode bloat / deep call chains:** transformations or generated code that inflate a method past thresholds, or call chains too deep for the inliner, quietly cut off the analysis. This is why two source programs that *look* equivalent can differ wildly in allocation behavior: one keeps the hot call inlinable and monomorphic, the other doesn't. ## Other subtleties - **Identity-sensitive operations:** taking the object's identity hash, using it as a monitor that might be shared, or reference-equality semantics can constrain the optimizer. - **Phasing:** it only runs after the method is JIT-compiled (hot) and the relevant calls inlined; cold or interpreted code allocates normally, so warmup behavior differs. - **Conservative joins:** if an object reaches a merge point (e.g. assigned in one branch, leaked in another), the worst-case use wins for the whole object. ## Practical guidance Don't *rely* on escape analysis for correctness, and don't contort code for it speculatively. But when a hot path's allocation profile matters: keep the hot method small enough to inline, prefer monomorphic call sites, avoid leaking temporaries into fields/returns when they don't need to be, and **verify** with tooling (JIT compilation logs / inlining diagnostics, allocation profilers) rather than assuming the optimization fired. The principal-level skill is recognizing that allocation cost can hinge on *inlining and dispatch shape*, not just on whether you literally wrote `return obj`.