THE ESCAPE ANALYSIS if it cannot outlive its scope, it need never touch the heap
Escape analysis asks whether an object allocated in a function can be reached after the function returns — stored in a global, returned, passed somewhere that keeps it. If it cannot escape, it does not need the heap at all: allocate it on the stack (or in registers), skip the garbage collector, and drop any synchronization it carried. The analysis is a reachability question over the object graph, and the payoff is large: stack allocation is nearly free where the heap is expensive.
THE TECHNIQUE does the allocation outlive its frame? if not → stack it
A local allocation is used in a few ways; toggle whether it is returned or stored globally. The demo decides whether it escapes — and so whether it needs the heap: live demo
HISTORY & CREDIT Park-Goldberg 1992 · Choi et al. 1999
“Every object lives on the heap.” — only the ones that escape their scope must. Most do not, and for those the heap is pure overhead. Escape analysis is the compiler proving an object is purely local and quietly putting it on the stack. cited
1992 · Park & Goldberg — escape analysis for functional languages (does a value outlive its let?). 1999 · Choi, Gupta, Serrano, Sreedhar & Midkiff — escape analysis for Java: stack allocation and lock elision for non-escaping objects; Blanchet independently. now · the JVM's scalar replacement of non-escaping objects; Go's stack/heap decision is escape analysis.
Escape is a reachability fact about the object graph. If no path from the outside reaches the object, the outside cannot tell where it lived — so it can live on the stack. Aliasing is the only thing that makes this hard. Choi et al. 1999
RECOMMEND FOR I-13 escapes over local allocations, computed
On the canonical compiler, three local arrays used only within their function escape zero times — nothing leaks, so nothing needs a heap:
$ i13 run escape.i13 # do local arrays escape their frame?
total_escapes = 0 -- value semantics: a write yields a new array, no aliasing
Recommend: i13 gets escape analysis's payoff for free — and this is the deep one. Its arrays are value-semantic and arena-backed: a write yields a new array (v[i]<-e desugars to a copy), there is no aliasing, and a value cannot be captured and mutated behind your back. So nothing escapes by construction — the exact property escape analysis works hard to prove, i13 has by design. The whole apparatus (heap, GC, the analysis to avoid them) is absent because the language never created the problem.