arthrop0d

Brief articles on varied topics.

Compiler Escape Analysis and Stack Versus Heap

compilersperformance

Escape analysis is a compiler’s determination of whether an allocated value can outlive the function that creates it. If the value cannot outlive that function, the compiler can usually keep it on the stack; if it might, the value must be available on the heap or be transformed in another safe way.

That decision matters because stack storage is tied to a function call, while heap storage is available independently of any one call. The choice affects allocation cost, memory lifetime, garbage collection, and sometimes cache behavior.

The problem escape analysis solves

A function’s stack frame is the memory associated with one invocation of that function. Local variables can live there efficiently: entering and leaving a function adjusts a stack pointer, rather than asking a general-purpose allocator for each value.

But a stack frame cannot be reclaimed while another part of the program still needs one of its values. Consider a function that returns a pointer to a local value:

type Point struct {
    X, Y int
}

func newPoint(x, y int) *Point {
    p := Point{X: x, Y: y}
    return &p
}

When newPoint returns, its stack frame is gone. The returned pointer must still refer to a valid Point, so the compiler must arrange for p to live somewhere that survives the call—typically the heap, a region of memory whose objects have lifetimes independent of individual function calls.

Without escape analysis, a compiler would have to use the heap whenever a value’s address was taken, or whenever a reference was passed to another function. That would be safe, but unnecessarily expensive. Many values are addressed temporarily and never outlive the current call.

What the analysis follows

Escape analysis examines how references to a value flow through the program. The central question is not simply “was this value allocated?” It is:

Can any usable reference to this value still exist after the creating function returns?

A value generally escapes when it is:

For example, passing a pointer to a helper does not automatically force a heap allocation. If the compiler can see that the helper only reads the value during the call and does not save the pointer, the value can remain on the stack. This is one reason inlining—replacing a call with the called function’s body—can improve escape decisions: it exposes more of the reference flow to the analysis.

The analysis is usually conservative. If the compiler cannot prove that a reference stays local, it must assume that it might escape. Separate compilation, indirect calls, reflection, interfaces, and opaque library code can make that proof harder. “Conservative” here means choosing a safe placement even when that placement may cost more.

How stack and heap placement change

For a non-escaping value, the compiler can place storage in the current stack frame:

func sum(a, b int) int {
    p := &Point{X: a, Y: b}
    return p.X + p.Y
}

Although this code takes the address of Point, the pointer is used only inside sum. A compiler may put p on the stack. It may go further and eliminate the object entirely, replacing its fields with registers or ordinary temporary values. That optimization is often called scalar replacement: treating an object’s individual fields as separate values instead of materializing the object.

By contrast, a returned pointer such as the one from newPoint requires storage that remains valid after the function returns. In a language with a garbage collector, the heap object can later be reclaimed when no references remain. In a language without one, the language’s ownership or destruction rules must ensure that the object is eventually released.

Escape analysis does not change the program’s visible lifetime rules. It changes the implementation used to honor them. A value that is logically local may be stack-resident; a value that is logically shared or long-lived needs storage with a correspondingly longer lifetime.

Why performance changes

Heap allocation commonly involves more work than stack allocation. A stack allocation can often be a pointer adjustment, while a heap allocation may require allocator bookkeeping, synchronization, and initialization. Heap objects also add work for a garbage collector, the runtime component that finds unreachable objects and reclaims their memory.

Heap placement can therefore increase:

The effects are especially visible in short-lived, high-volume code such as request handling, serialization, logging, and collection-building loops. A small allocation repeated millions of times can become a measurable part of the profile.

Stack placement is not automatically free or always faster. Large stack values consume stack space, and some runtimes grow or move stacks. A long-lived value also cannot simply be forced onto a stack that will disappear. Correctness comes first; escape analysis is the compiler’s way to use the cheaper lifetime when it can prove that it is safe.

Finding it in compiler output

In Go, compiler diagnostics can expose these decisions. Building with escape-analysis diagnostics, for example with -gcflags=-m, may produce messages such as moved to heap or escapes to heap. Those messages describe the compiler’s reasoning, not necessarily a one-to-one count of runtime allocations: later optimization may remove an object or replace it with scalar values.

The practical lesson is to treat escape output as a performance clue, then verify its effect with benchmarks and profiles. Reducing an escape can help, but redesigning code solely to silence a diagnostic may make it harder to read or may move cost elsewhere. Escape analysis is a compile-time lifetime proof that lets the runtime use the stack when the program’s references do not require the heap.

← All articles