The Call Stack, Memory Heap, and Execution Context in JavaScript

To write high-performance web applications, you must look beyond JavaScript syntax and understand how the engine executes code and manages memory.

At runtime, the JavaScript engine (like Google's V8 or Apple's JavaScriptCore) relies on three core components: the Execution Context, the Call Stack, and the Memory Heap. Misunderstanding how these pieces fit together is the leading cause of memory leaks, UI freezes, and "maximum call stack size exceeded" crashes.

1. What is an Execution Context?

The Execution Context is an abstract environment created by the JavaScript engine to evaluate and execute code. Think of it as a wrapper that contains all the environment details (scope, arguments, variables, and this value) needed to run a block of code.

There are three types of Execution Contexts:

1. Global Execution Context (GEC): Created by default when your script starts. It sets up the global scope, the global object (window in browsers), and binds this to it. There is only ever one GEC.
2. Function Execution Context (FEC): Created dynamically every time a function is invoked. Each function call gets its own FEC.
3. Eval Execution Context: Created when code is executed inside the eval() function (discouraged in modern development).

The Phases of Execution Context

Every execution context goes through two distinct lifecycle phases:

Phase A: Creation Phase

Before executing a single line of code, the engine sets up the environment:

• Variable Object (VO) / Lexical Environment: Registers variable and function declarations.
• Hoisting: Variables declared with var are initialized to undefined. Functions are loaded entirely into memory. Block variables (let, const) are registered but remain uninitialized (TDZ).
• Scope Chain: Creates a link to its outer environment.
• This Binding: Evaluates the value of this.

Phase B: Execution Phase

The engine reads the code line-by-line, assigns values to variables, and executes statements.

2. The Call Stack (Execution)

The Call Stack is a mechanism used by the JavaScript engine to keep track of its place in a script that calls multiple functions. It operates on a LIFO (Last In, First Out) data structure.

• When a function is called, the engine creates a new Function Execution Context and pushes it onto the Call Stack.
• The function at the top of the stack is the one currently executing.
• When that function completes, its context is popped off the stack, and execution resumes where it left off in the calling context below it.

Stack State during execution:
 
  [ FEC: c() ]  ← Executing now
  [ FEC: b() ]
  [ FEC: a() ]
  [ GEC      ]  ← Bottom of stack

Stack Overflow

Because stack memory is fixed and limited, pushing too many execution contexts onto the stack will crash the program. This is known as a Stack Overflow.

// Infinite recursion with no base case
function recurse() {
  recurse(); 
}
recurse(); // RangeError: Maximum call stack size exceeded

3. The Memory Heap (Storage)

While the Call Stack tracks the order of function execution and stores small, fixed-size variables (primitives like numbers, booleans, and stack-allocated references), the Memory Heap is a large, unstructured region of memory used to store reference values (objects, arrays, and functions).

Because objects can grow dynamically at runtime, they cannot be stored in the rigid structures of the stack. Instead:

1. The engine allocates memory for the object in the Memory Heap.
2. It stores the memory address (reference) to that heap space on the Call Stack.

CALL STACK                    MEMORY HEAP
[ objRef (address: 0x101) ] ───> [ { name: "Alice", age: 25 } ]
[ primitiveVal (200)      ]

4. Stack vs. Heap: Comparison Matrix

5. Garbage Collection Basics

Since heap memory is large but finite, the engine must release memory for objects that are no longer needed. This process is called Garbage Collection (GC).

Modern JavaScript engines use a strategy called Mark-and-Sweep:

1. Roots: The GC starts from a set of "root" objects (e.g., the global window object, active Call Stack variables).
2. Marking: The GC traverses the memory heap, recursively following links from the roots. Every object it can reach is "marked" as reachable.
3. Sweeping: The engine scans the entire heap and deallocates memory for any objects that were not marked.

[ Root: Window ]
      │
      ├──> [ Object A ] (Reachable - Marked)
      │
      └──> [ Object B ] (Reachable - Marked)
           
           [ Object C ] (Unreachable - Swept & Deleted)

[!TIP] Old engines used a Reference Counting GC algorithm, which simply tracked how many references pointed to an object. This failed during circular references (Object A points to Object B, and Object B points to Object A), causing memory leaks even when both objects were completely unreachable from the roots. Mark-and-Sweep solves this because unreachable cycles are never traversed from roots.

6. Common Interview Coding Pitfalls

Trap #1: Closure-Induced Memory Leak

How does the memory footprint behave in this code?

function makeLeaker() {
  const giantData = new Array(1000000).fill("data");
  
  return function() {
    console.log("I am running");
  };
}
 
const leak = makeLeaker();

Answer: giantData is leaked and cannot be garbage collected. Even though the returned function doesn't explicitly log or use giantData, it retains a reference to its parent Lexical Environment (which contains giantData). As long as the leak reference exists globally, the entire parent scope is kept in the memory heap.

Trap #2: Unintentional Global Variables

What is the memory risk here?

function processData() {
  largeObject = { data: new Array(500000) }; // Missing var/let/const
}
processData();

Answer: largeObject is attached to the global object (window.largeObject). Because global objects are GC roots, largeObject will remain in the heap permanently, even after processData() finishes execution, until the browser window is closed or refreshed.

7. Key Takeaways

• The Execution Context is the environment where JavaScript code is evaluated.
• The Call Stack uses LIFO order to manage function calls and store primitive values.
• The Memory Heap allocates unstructured memory for dynamically-sized objects, arrays, and closures.
• The stack stores references (pointers) to objects that reside in the heap.
• Modern engines use Mark-and-Sweep garbage collection, tracing memory from global and stack roots to clean unreachable allocations.
• Keep functions shallow and clear references to unused large data sets to avoid stack overflows and memory heap leaks.