Stack, Heap, and Memory Layout

Your Code Lives in Two Places

Every variable you create, every object you build, every function you call — it all lives somewhere in memory. Not in some abstract cloud. In actual bytes, at actual addresses, managed by actual allocation strategies.

JavaScript hides this from you. There is no malloc, no pointer arithmetic, no manual deallocation. But the engine still has to make the same decisions that C programmers make: where does this data go? How much space does it need? When can I reclaim it?

The answer depends on two memory regions with fundamentally different properties: the stack and the heap.

If you don't understand the difference, you won't understand why closures have a memory cost, why deep recursion crashes your tab, or why some code allocates ten times more garbage than equivalent code that looks nearly identical.

The Stack: Fast, Rigid, Automatic

The call stack stores execution contexts — one frame per function call. Each frame contains:

• Local primitives — numbers, booleans, undefined, null, and small strings (SMI and HeapNumber in V8)
• References to heap objects — the pointer lives on the stack, the object lives on the heap
• The return address — where to continue execution when this function finishes
• Arguments — the values passed into the function

function multiply(a, b) {
  const result = a * b;  // 'result' is a number — lives on stack
  return result;
}

function calculate() {
  const x = 10;          // stack: x = 10
  const y = 20;          // stack: y = 20
  const answer = multiply(x, y);  // new frame pushed
  return answer;
}

calculate();

When calculate calls multiply, a new stack frame is pushed. When multiply returns, its frame is popped — instantly. No GC needed, no deallocation logic. The stack pointer just moves back.

Stack Overflow Is Literally Running Out of Stack

The stack has a fixed size — typically around 1MB in V8. Blow past it and you get the famous RangeError: Maximum call stack size exceeded:

function recurse() {
  return recurse();  // each call adds a frame, nothing ever pops
}

recurse();  // RangeError after ~10,000-15,000 frames

This is not a bug in your logic (well, it is). It is a physical memory limit. Each frame takes space, and the stack cannot grow.

The Heap: Flexible, Complex, Garbage-Collected

Everything that isn't a primitive or a stack frame goes on the heap: objects, arrays, functions, closures, strings longer than a certain threshold, Maps, Sets, Promises, class instances — all of it.

function createUser(name) {
  // This object is allocated on the heap
  // The variable 'user' on the stack holds a pointer to it
  const user = {
    name: name,
    scores: [100, 95, 87],  // the array is also on the heap
    greet() {               // the function is also on the heap
      return `Hi, I'm ${this.name}`;
    }
  };
  return user;
}

const alice = createUser('Alice');
// createUser's stack frame is gone
// but the object persists on the heap because 'alice' still references it

Unlike the stack, heap allocation is dynamic — objects can be any size and live for any duration. But this flexibility comes at a cost:

• Allocation is slower — the allocator must find a free region of the right size
• Deallocation is complex — the garbage collector must determine when objects are unreachable
• Fragmentation — allocated and freed regions intermix, leaving gaps
• No predictable layout — cache locality suffers compared to the contiguous stack

Why Closures Force Heap Allocation

This is the part most developers miss. When a function closes over a variable, that variable cannot live on the stack — because the stack frame where it was declared will be destroyed when the function returns.

function createCounter() {
  let count = 0;  // normally this would be stack-only

  return function increment() {
    count++;       // but increment() outlives createCounter()
    return count;  // so 'count' must survive frame destruction
  };
}

const counter = createCounter();
// createCounter's stack frame is gone
// but counter() still needs access to 'count'
counter();  // 1
counter();  // 2

V8 handles this with a Context object — a heap-allocated structure that holds the closed-over variables. The inner function gets a hidden reference to this Context, not to the stack frame.

This is why closures have a memory cost: they force variables from stack to heap. Not all variables in the enclosing scope — V8 is smart enough to only capture the ones actually referenced. But if a closure references even one variable, V8 creates a Context object.

V8's Actual Memory Layout

At a high level, V8 divides its heap into several spaces:

Most objects you create land in New Space first. If they survive garbage collection, they get promoted to Old Space. Large objects skip New Space entirely.

Stack vs Heap at a Glance

Production Example: Closure Leak in Event Handlers

// BAD: This leaks because the closure captures 'hugeData'
function setupHandler(element) {
  const hugeData = new Array(1_000_000).fill('x');  // ~8MB
  const processedResult = hugeData.map(x => x.toUpperCase());

  element.addEventListener('click', () => {
    // Only needs processedResult, but hugeData may also be retained
    // because both live in the same Context
    console.log(processedResult.length);
  });
}

// GOOD: Isolate the heavy computation
function setupHandler(element) {
  const processedResult = computeResult();

  element.addEventListener('click', () => {
    // Only processedResult is in scope — hugeData was never here
    console.log(processedResult.length);
  });
}

function computeResult() {
  const hugeData = new Array(1_000_000).fill('x');
  return hugeData.map(x => x.toUpperCase());
  // hugeData is now unreachable — GC can reclaim it
}

The fix is structural: move the temporary into a function that returns only what you need. The heavy data becomes unreachable as soon as that helper function returns.