Stack vs Heap

1. What Is It?

When your program runs, its memory is split into regions with different rules. Two matter most: the stack and the heap.

• The stack holds function call frames — local variables, parameters, return addresses. It grows as functions are called and shrinks as they return. Allocation is a single pointer bump; deallocation happens automatically when the function exits.
• The heap holds data whose lifetime isn't tied to a single function call — objects that need to outlive the function that created them, or whose size isn't known at compile time. Allocation is more expensive, and cleanup is either manual (C/C++) or handled by a garbage collector (Python, Java).

Without this split, the language couldn't cheaply reuse memory across function calls (stack), nor let data live past the function that created it (heap).

2. How It Works

The stack: last in, first out

Every function call pushes a stack frame onto the stack. The frame holds:

• Parameters
• Local variables
• The return address (where to resume in the caller)
• Saved registers

When the function returns, its frame is popped — the stack pointer moves back up, and that memory is instantly reusable. This is why stack allocation is essentially free: a single instruction adjusts one register.

-+ResetFullscreen

The heap: long-lived, manually managed

The heap is a large memory pool the program requests chunks from. In C++, new and malloc ask for heap memory; you must later delete or free it. In Python and Java, the language runtime allocates on the heap for you and a garbage collector reclaims unreachable memory.

Copy
// C++ — stack and heap side by side
void f() {
    int localValue = 42;                  // on the stack, lives until f() returns
    int* heapValue = new int(42);         // on the heap, lives until 'delete'
    delete heapValue;                     // must free manually
}   // localValue is reclaimed automatically; heap leak if delete was forgotten

Copy
// Java — primitives on stack (as frame locals), objects always on heap
void f() {
    int localValue = 42;                  // in the stack frame
    Point point = new Point(1, 2);        // the Point object is on the heap;
                                          // 'point' (a reference) is in the stack frame
}   // frame pops; Point is collectible when no references remain

Copy
# Python — integers, strings, everything is a heap object;
# names (variables) are references stored in the frame
def f():
    localValue = 42                       # name 'localValue' in the frame
                                          # but the int object '42' is on the heap
    nums = [1, 2, 3]                      # list object on the heap

What lives where

Why objects default to heap in Python and Java

Objects can outlive the function that created them — you might return one, put it in a list, or hand it to another thread. A stack frame only exists while the function runs. If you let someone hold a pointer into a popped frame, you get a dangling pointer. Python and Java side-step this entirely: every object lives on the heap, so references stay valid as long as any code still holds one.

C++ lets you put objects on the stack anyway, because it's faster and the compiler can enforce lifetime via scope. But returning a pointer to a stack local is a classic bug:

Copy
// C++ — DO NOT DO THIS
int* buggy() {
    int localValue = 42;
    return &localValue;          // dangling: frame is gone as soon as we return
}

3. What You Actually Need to Know

• Stack memory is tiny. Typical defaults: 8 MB for the main thread on Linux and macOS (check with ulimit -s); secondary threads are smaller — 512 KB on macOS, around 8 MB on Linux glibc (set via pthread_attr_setstacksize). JVM threads default to ~512 KB–1 MB (-Xss). Huge arrays or deep recursion overflow it — you get a StackOverflowError (Java), RecursionError (Python), or a segfault (C++).
• Heap memory is large but slow-ish. Allocation involves bookkeeping (finding a free block, updating free lists). For hot paths, allocating many small objects on the heap is a measurable cost.
• Stack allocation is automatic; heap isn't. In C++, every new needs a matching delete. In Python/Java, the GC handles it — but "unreachable" is what matters, and holding onto references (e.g., a cache, a static list) keeps objects alive longer than you'd expect.
• Size must be known at compile time to go on the stack (in C++). Runtime-sized arrays go on the heap. Python and Java don't really give you the choice — objects always go on the heap.
• Debugging clues:
  • StackOverflowError / RecursionError / segfault in a recursive function → runaway recursion. Missing base case, or the input was too deep. Convert to iteration or increase stack size.
  • Accessing freed memory (C++) → classic "use after free". Tools: AddressSanitizer, Valgrind.
  • Memory leak growing over time (C++) → a new without delete, or a cycle your ref-counted smart pointers can't break.
  • High memory usage that doesn't go down (Java/Python) → something still holds references. Look for caches, static collections, listener lists.

4. Language Differences

• C++: you pick stack or heap per object. Stack objects are destroyed deterministically when their scope ends (enables RAII — resource cleanup tied to object lifetime). Heap objects need delete or a smart pointer (std::unique_ptr, std::shared_ptr).
• Java: primitives on the stack frame, objects always on the heap, GC reclaims them. JIT can sometimes "escape-analyze" short-lived objects onto the stack as an optimization, but from your code's perspective every object is heap.
• Python: everything is a heap object, including small ints and strings (which are often cached/interned). Reference counting + cyclic GC handles cleanup. Names in the local frame are just references to heap objects.

Go, Rust, and C# do similar things for similar reasons. Go adds escape analysis at compile time — if an object provably can't outlive its stack frame, it stays on the stack; otherwise it escapes to the heap.

5. Tradeoffs & Decisions

• Allocate on the stack when you can. Faster, no GC pressure, automatic cleanup. In C++ this is a routine choice; in Python/Java the language chooses for you.
• Use the heap when the object must outlive its creating function, when its size is only known at runtime, or when it's too big for the stack (large buffers, images).
• Deep recursion → iteration or explicit stack. If recursion depth depends on input, it will overflow. Convert to a loop with a heap-allocated stack structure (list, ArrayDeque, std::stack).
• Many small allocations → pool or arena. In hot paths, allocating millions of tiny objects on the heap thrashes the allocator and the GC. Reuse buffers, preallocate, or pool.
• In C++, prefer value types and unique_ptr over raw new. Raw new and delete invite leaks, double frees, and dangling pointers. Smart pointers tie heap lifetime to scope.

If you see allocation profiling dominated by a small struct, move it to the stack or reuse a buffer. If you see a StackOverflowError, either bound the recursion or flip to iteration with an explicit heap-allocated stack.

6. Interview Cheat Sheet

• The stack holds function frames (locals, parameters, return addresses). Allocation is a pointer bump; deallocation is automatic on return. Fast but small and scope-bound.
• The heap holds long-lived data — anything that must outlive the function that created it, or is too big / runtime-sized. Slower to allocate; cleanup is manual (C/C++) or via GC (Python/Java).
• Java/Python objects always live on the heap; primitives and references live on the stack frame.
• C++ lets you choose — stack for speed and deterministic lifetime, heap via new / smart pointers for long-lived or large data.
• Classic bugs: stack overflow (runaway recursion), dangling pointer (keeping a pointer to a popped frame in C++), memory leak (forgotten delete or lingering reference in GC languages).

Follow-ups:

• "Why can't you just put everything on the heap?" — Heap allocation is slower and fragments memory. Stack allocation is nearly free and cleans up automatically. Languages default to heap only where they must (object lifetimes outliving frames).
• "What causes a stack overflow?" — Usually unbounded recursion, occasionally a massive local variable (e.g., int huge[10_000_000] in C++). Each call consumes a frame; the stack is small.
• "How do Java/Python avoid dangling pointers?" — They allocate objects on the heap and rely on GC. As long as any reference exists, the object stays alive; once no references remain, the GC reclaims it.
• "What is RAII?" — Resource Acquisition Is Initialization: in C++, tie a resource (memory, file, lock) to the lifetime of a stack object. The destructor runs deterministically on scope exit and releases the resource.