The Stack & the Heap

Two places a value can live

Every value your program creates lives in one of two regions:

• The stack — a contiguous, per-goroutine region that grows and shrinks with function calls. Each call pushes a frame (its parameters and locals); returning pops it. Allocation is a single pointer bump; deallocation is automatic.
• The heap — a process-wide region for values that must outlive the function that created them. Allocation goes through the memory allocator, and reclamation is the job of the garbage collector.

The crucial Go fact: you don’t choose. There is no malloc, no stack/heap keyword. The compiler decides during escape analysis, and new(T) or &x does not force the heap.

graph TD
V["a value is created"] --> Q{"can it be proven<br/>not to outlive<br/>its function?"}
Q -->|"yes"| S["stack frame<br/>(freed on return)"]
Q -->|"no — it escapes"| H["heap<br/>(reclaimed by GC)"]

The stack: a frame per call

When a goroutine calls a function, the runtime pushes a frame holding that call’s locals and arguments. When the function returns, the frame is popped — every local in it is gone at once, for free. No bookkeeping, no GC involvement.

This program shows the discipline: the deeper you call, the more frames stack up, and they unwind in exactly reverse order.

package main

import "fmt"

func work(depth int) {
if depth == 0 {
	return
}
x := depth * depth // a local — lives in this frame only
fmt.Printf("enter depth=%d (x=%d)\n", depth, x)
work(depth - 1) // pushes a new frame
fmt.Printf("leave depth=%d\n", depth)
}

func main() {
work(3)
// Notice the symmetric enter/leave: frames pop in reverse (LIFO).
}

Stacks grow — that’s why goroutines are cheap

An OS thread reserves a big stack (often ~1 MB) when it’s created. A goroutine starts with a tiny ~2 KB stack and grows on demand. When a call would overflow the current stack, the runtime:

1. allocates a larger stack segment,
2. copies the existing frames into it,
3. rewrites every pointer that referred into the old stack,
4. and resumes as if nothing happened.

graph LR
A["~2 KB stack<br/>(goroutine start)"] -->|"call would overflow"| B["allocate 2× stack"]
B --> C["copy frames + fix pointers"]
C --> D["resume on bigger stack"]

Because stacks are small at birth, you can spawn hundreds of thousands of goroutines; because they grow, deep recursion still works. (Growth isn’t free — the copy is O(stack size) — but it’s rare and amortized.) The same machinery shrinks stacks that have become over-large, returning memory to the runtime.

Watching the heap move

You can’t directly observe an individual stack vs heap decision at runtime, but you can watch the heap grow as escaping allocations pile up. runtime.ReadMemStats reports cumulative heap activity:

package main

import (
"fmt"
"runtime"
)

type Point struct{ X, Y int }

// newPoint returns a pointer, so the Point escapes to the heap.
func newPoint(x, y int) *Point { return &Point{x, y} }

func readMallocs() uint64 {
var m runtime.MemStats
runtime.ReadMemStats(&m)
return m.Mallocs // cumulative count of heap objects allocated
}

func main() {
before := readMallocs()

pts := make([]*Point, 0, 1000)
for i := 0; i < 1000; i++ {
	pts = append(pts, newPoint(i, i)) // 1000 heap allocations
}

after := readMallocs()
fmt.Printf("heap objects allocated by the loop: ~%d\n", after-before)
fmt.Println("kept alive:", len(pts))
}

Returning *Point forces each Point onto the heap, so Mallocs climbs by ~1000. Build the slice as []Point of values instead and most of that heap traffic disappears — the lever every Go performance guide pulls.

Reference

See also

• escape analysis — the compiler pass that makes the stack-vs-heap call.
• the memory allocator — what actually services a heap allocation.
• the garbage collector — how heap memory is reclaimed.
• GC, stacks & escape analysis (concurrency) — the same story from the goroutine-cost angle.

Next: how the compiler actually decides what escapes — escape analysis.

Related topics