Memory, the Stack & the Heap
The problem
Every running program needs somewhere to keep its data, and different kinds of data have very different lifetimes — a function's local variables disappear when it returns, while an object you create might need to outlive the function that created it. Programs need two different memory regions with two different rules to serve both needs.
Why now
Recursion already relies on 'the call stack' informally; arrays and lists already rely on memory existing somewhere. This topic makes that informal reliance precise — showing exactly what the stack and heap are, why recursion has a depth limit, and why some values can be returned safely from a function while others can't.
Mental model
The stack is a tightly disciplined pile of function-call frames — push on call, pop on return, strictly LIFO, which is why deep recursion can overflow it. The heap is a loosely organized pool where anything with an unpredictable lifetime lives, managed by allocation and (in garbage-collected languages) automatic reclamation once nothing references it anymore.
Requires
- RecursionProgramming Fundamentals
Understanding stack overflow and call-stack depth requires already knowing recursion produces one call frame per call — this topic explains the mechanism recursion was informally relying on.
- Stacks & QueuesComputer Science Fundamentals
The call stack is a literal instance of the stack data structure — this topic is where that data structure is shown to be a real, physical part of how programs execute, not just an abstraction.
Helps
- Mutability & ReferencesProgramming Fundamentals
Whether a value lives on the stack (copied) or the heap (referenced) directly determines whether mutability-and-references' aliasing behavior applies to it — useful context, not required to grasp the memory model itself.
Unlocks
Used in
- Stack overflow errors from unbounded or excessively deep recursion
- Garbage collection in managed languages (JavaScript, Java, Python)
- Manual memory management and its bug classes (use-after-free, memory leaks) in C/C++
- Understanding closures' memory implications — captured variables live on the heap, not the stack
Projects
- Write a recursive function with no base case and observe the stack overflow error and its message directly
- Diagram, by hand, the stack frames and heap allocations created by a small program with a few function calls and one closure
Examples
- A local number variable is pushed onto the stack frame and destroyed automatically when the function returns
- An object returned from a function must live on the heap, because its lifetime outlives the stack frame that created it
Resources
Mastery checklist
- I can explain the difference between stack and heap memory and what lives in each
- I can explain why deep or infinite recursion causes a stack overflow
- I can explain, at a high level, how garbage collection reclaims heap memory
- I can predict whether a given value in code lives on the stack or the heap