Every program you write runs in memory. The variables you declare, the objects you create, the function calls you make - all of it lives somewhere in RAM. Most of the time you don’t think about this, especially in garbage-collected languages where memory management is handled for you. But the underlying model - stack and heap - shows up everywhere: in error messages (“stack overflow”), in performance characteristics, in debugging tools, and in the behavior of programs that do unexpected things.

Understanding how memory actually works makes these things less mysterious.

The Process Address Space

When an operating system runs a program, it gives it a virtual address space - a range of memory addresses the program can use. The OS handles the mapping from virtual addresses to physical RAM transparently. From the program’s perspective, it has a large, contiguous block of memory.

This address space is divided into regions with different purposes. The stack and heap are two of them.

The Stack

The stack is a region of memory managed automatically by the CPU and runtime. It works exactly like a stack data structure: last in, first out.

When a function is called, a “stack frame” is pushed onto the stack. This frame contains:

• The function’s local variables
• The function’s parameters
• A return address (where to jump back when the function returns)
• Saved registers

When the function returns, its frame is popped off the stack. All of that memory is immediately available for reuse.

void foo() {
    int x = 10;       // lives on the stack, in foo's frame
    int y = 20;       // also on the stack
    bar(x + y);       // bar's frame is pushed on top
}                     // foo returns: its frame is popped, x and y are gone

The stack has several important properties:

Allocation is free. “Allocating” stack memory just means decrementing a stack pointer register by the size of the frame. It’s a single CPU instruction.

Deallocation is automatic. When a function returns, the stack pointer moves back up. No tracking, no garbage collection needed.

Lifetime is tied to function scope. Memory exists for exactly as long as the function is running. You can’t return a pointer to a local variable and use it after the function returns - the memory is gone (this is a dangling pointer, a common source of bugs in C and C++).

The stack has a fixed, limited size. Typically 1-8 MB depending on the platform and configuration. Deep recursion can exhaust the stack - this is what “stack overflow” means. Each recursive call pushes a new frame; too many frames and you run out of stack space.

The Heap

The heap is a region of memory for data that needs to outlive a function call, or whose size isn’t known at compile time.

Heap allocation is explicit. In C/C++, you call malloc/new to allocate and free/delete to deallocate. In garbage-collected languages (Java, Python, Go, JavaScript), the runtime tracks heap-allocated objects and frees them automatically when they’re no longer reachable.

int* create_array(int size) {
    // Stack: can't do this - size not known at compile time (in older C standards)
    // and would be deallocated when function returns anyway

    // Heap: allocates memory that persists after this function returns
    int* arr = malloc(size * sizeof(int));
    return arr;  // safe: the memory lives until someone calls free(arr)
}

Heap allocation is slower than stack allocation. The runtime needs to find a contiguous block of free memory of the right size, track that it’s in use, and eventually reclaim it. For languages with garbage collectors, the GC itself has overhead and occasionally pauses your program.

The heap is also prone to fragmentation: after many allocations and frees, the heap can have many small free regions that can’t satisfy a large allocation even though total free space is sufficient.

Stack vs Heap: The Practical Breakdown

	Stack	Heap
Size	Small (MB)	Large (GB)
Allocation speed	Very fast	Slower
Deallocation	Automatic, immediate	Manual (C/C++) or GC
Lifetime	Tied to function scope	Explicit or GC-managed
Access pattern	Sequential	Random

In a garbage-collected language, you rarely make this choice explicitly. The language decides: small, primitive values may live on the stack; objects almost always live on the heap. In Go, the compiler performs escape analysis to determine whether a value can safely live on the stack or must be heap-allocated. In Java, the JVM handles it similarly.

In C and C++, you make this choice constantly. Understanding the tradeoffs matters for correctness (don’t return pointers to stack-allocated memory) and performance (prefer stack allocation for small, short-lived data; heap for everything else).

Why This Matters in Higher-Level Languages

Even if you write Python or JavaScript, the stack/heap model affects your work:

Stack overflows in recursion: Python’s default recursion limit is 1000 frames. Beyond that, you get a RecursionError. This limit exists because each recursive call adds a frame to the stack, and the stack is finite.

Performance characteristics: allocating many small objects on the heap creates GC pressure. A hot loop that creates many short-lived objects may cause GC pauses you wouldn’t get if you reused objects or used stack-allocated types.

Memory leaks in GC’d languages: “memory leak” usually means holding references to objects longer than necessary, preventing the GC from reclaiming them. Event listeners that are never removed, caches that never evict, global state that accumulates - these are heap objects that aren’t freed because the program still holds references to them.

Value vs reference semantics: in languages that distinguish these (Go, Rust, C#), passing a value copies the data (stack-like semantics). Passing a reference/pointer means multiple parts of the program can access the same heap object, which creates aliasing and the possibility of unexpected mutation.

The Mental Model

Think of the stack as a scratchpad that functions use and discard. Think of the heap as long-term storage for data that needs to survive function calls or whose size you don’t know ahead of time.

When something is on the stack, its lifetime is clear and its cleanup is automatic. When something is on the heap, something has to decide when it’s done being used. In GC’d languages that “something” is the runtime. In manual memory management languages, it’s you.

Most memory-related bugs - use-after-free, dangling pointers, memory leaks - come from confusion about which memory lives where and who’s responsible for cleaning it up.