In part 1, we covered the overall functioning of the JavaScript engine, focusing on the memory heap, the causes of memory leaks, and strategies for preventing them. In this part 2, we’ll explore another critical component of the JavaScript engine: the call stack.

Understanding the call stack is crucial for knowing how JavaScript functions are executed and how asynchronous operations fit into the larger JavaScript Runtime Environment which we will deep dive in part 3.

Here is the table of contents for your easy access.

An overview of the JS Engine & Memory Heap
Call Stack and Execution Context in details
Event Loop and the Concurrency Model – Task Queue
Event Loop and the Concurrency Model – Microtask Queue (coming soon)
Advanced JavaScript: Chunking, Threading, Parallelism, and Web Workers (coming soon)
Explanation of Interview Question (coming soon)

Let’s first understand what call stack is.

Call Stack Intro

The Call Stack is a data structure that tracks the program’s execution sequence. Think of it as a stack of plates; you can only add or remove plates from the top. Similarly, the Call Stack follows a Last In, First Out (LIFO) principle. Whenever a function is called, it’s added (or “pushed”) to the top of the stack. And when the function completes its execution, it’s removed (or “popped”) from the top.

One important aspect to note is that primitive values (like numbers, strings, and booleans) are directly saved in the Call Stack, more precisely, they are stored in the Variable Environment of the current execution context on the Call Stack (we will explore more in details in the following sections). So, when you declare a variable like let x = 10;, that value 10 is stored directly on the Call Stack. This contrasts with more complex types, like objects and arrays, which are stored in the Memory Heap and referenced in the Call Stack as mentioned in the Memory Heaps section in part 1.

In JavaScript, the Call Stack plays a crucial role in managing function calls, ensuring they execute in the correct order, and maintaining the variables’ and function calls’ current state. If you’ve ever encountered a “Maximum call stack size exceeded” error, it was due to the stack overflowing – usually from a function that calls itself recursively without an exit condition.

Before diving into the Call Stack, let’s first understand what ‘Execution Context‘ means in JavaScript.

Execution Context

In “What is Hoisting in JavaScript?” article, we talked about what “Execution context” is and how it creates the hosting. Let’s deep dive into it in this article.

The Execution Context is essentially the environment in which JavaScript code runs. Think of it as a box that encompasses variables, functions, and other details pertaining to a particular segment of your code.

In your JavaScript code,

One global execution context is automatically created
and each function call creates a new execution context stacking it on top of any exisiting contexts.

Let’s take a look at this example.

Even if we see nothing on the screen, a global execution context is working behind the scenes. Try typing this in the browser’s DevTool and you will see the Window object, even without any JS code. Each browser tab has its own Window object.

Now let’s take a look at the example of function calls. For each functional call, a new execution context is created. In main.js, let’s add the below code and run:

function second() {
  let step;
  console.log(step);
}

function first() {
  let step = 2;
  console.log(step);
  second();
}

let step = 1;
console.log(step);
first();
console.log(step);

You will get:

1
2
undefined
1

Is it something you expected? Let’s break down how it all works in details.

Execution Context in Details

When your JavaScript code runs, it operates within an “execution context”. Each context undergoes two phases: the creation phase and the execution phase. Moreover, every execution context comprises three essential components.

1. Variable Environment

As briefly mentioned above, it is where variables, function declarations, and function arguments are stored and managed. The variable environment consists of the environment record, hoisting and scope chain.

2. Lexical Environment

As I explained in my hoisting article, this provides storage for variables and function declarations. It’s conceptually similar to the variable environment but also includes the concept of the “outer environment”, linking to the lexical scope of the current context. It also remembers where everything was created, which is important for some advanced features like closures.

3. `this` Binding

It contains a reference to the object on which a method is called or the current context in other scenarios. Check out this article to learn more about this. As we show above, for global code, this typically refers to the global Window object in browsers. Inside a function, the value of this depends on how the function is called.

Now, using our code as an example, let’s see these concepts in action.

Call Stack in Action

Let’s revisit the code again.

function second() {
  let step;
  console.log(step);
}

function first() {
  let step = 2;
  console.log(step);
  second();
}

let step = 1;
console.log(step);
first();
console.log(step);

Here’s how the call stack behaves as this code executes. At the moment, the call stack is empty.

As soon as the JS file loads and starts, the global execution context (GEC) is created and its variable environment initially hoists the step variable and initialised to undefined.

The code starts executing. The global variable step is set to 1 (line 12), and it’s logged (line 13).

Output:

Next the function first() is called (line 14), creating its own execution context where its local step variable is initialised to 2 (line 7) stored in its own variable environment. This new execution context stacks on top of the GEC in the call stack due to LIFO (Last In First Out) nature of the stack. And it’s logged (line 8).

Output:

1
2

Inside first(), function second() is called, creating another execution context and variable environment (line 9). Its step is undefined (line 2) and then logged (line 3).

1
2
undefined

After second() finishes execution, it pops off from the call stack.

It returns to first(), and as it also finishes it’s execution, the first() pops off from the call stack.

The global step is logged again (line 15). The GEC is the foundational layer of the call stack. It’s the base, or the bottom-most layer and it remains for the duration of the script or application’s life cycle.

DevTools

In today’s modern browsers, they allow us to visually observe the call stack’s behaviour. Let’s dive into how to use Chrome’s DevTools to observe the call stack in action.

Fire up Chrome and open DevTools, and navigate to the Source Tab > Page and click on main.js.

On the right-hand panel, we will spot sections detailing the current Scope and the execution contexts in the “Call Stack“.

Now let’s click on line number 14 which will set the break point indicated by the blue arrow. Upon reloading the page, the script execution will pause at this line. Notice the current value in the Scope and execution context in Call Stack. At the moment, the step value is 1 and current execution context is GEC displayed as (anonymous).

Let’s set another break point on line number 9 and click the resume button. It will show the current local step value as 2 which is logged in the Console, and the first() function now stacks up in the Call Stack.

Next, let’s add another break point to line number 4 so that we can run the console.log on line 3, and click the resume button. At this point, the step value is undefined which is logged in the Console and the second() function is added to the Call Stack.

Now, let’s set the break point on line number 10 and click the resume button. As the second() completes its execution, it pops off from the Call Stack leaving behind first() and GEC in the Call Stack.

Let’s place one more break point on line number 16 which is the point where the script nears its end. It shows the step value as 1 logged in the Console and the first() function pops off from the Call Stack.

And finally when we click the resume button, the script has completed its run causing the GEC to be removed from the Call Stack as well.

With Chrome’s DevTools, visually tracking and understanding the call stack’s behaviour becomes an insightful experience, aiding in both learning and debugging processes.

StackOverflow

A StackOverflow (which might ring a bell as the name of a popular developer forum) happens when the call stack exceeds its maximum size threshold. In simpler terms, it occurs when too many execution contexts are stacked onto the call stack causing it to “overflow”. One of the examples is recursion without a base case where a function calls itself indefinitely.

Let’s see the case of endless recursion, where a function continuously calls itself without any stopping criteria:

function recursiveFunction() {
  recursiveFunction();
}

recursiveFunction();

In this example, each recursiveFunction() invocation adds a new execution context onto the call stack and without any base case to stop the recursive calls, the call stack soon runs out of space resulting in a StackOverflow.

It’s vital to ensure there is a condition that halts the recursive calls before the call stack is exhausted. Otherwise the application will crash causing the bad user experience. If you want to learn how the recursion works comparing with the iterable solutions, make sure to check out this recursion article.

Slow function in Call Stack

As explained in part 1, JavaScript is known for its synchronous and single-threaded nature. This essentially means that it can execute one thing at a time in a specific order.

Also we had a look at how the longTaskFunc() affects the synchronous and single-threaded nature in part 1. Let’s take a look at a scenario to better understand the impact of the longTaskFunc() on the call stack.

function second() {
  let step;
  console.log(step);
}

function longTaskFunc() {
  // this function contains operations that take a long time
  for (let i = 0; i < 1e9; i++) { } 
  console.log('Long Task Function');
}

function first() {
  let step = 2;
  console.log(step);
  longTaskFunc();
  second();
}

let step = 1;
console.log(step);
first();
console.log(step);

Let’s see how this sequence affect the call stack. By the time we reach line 14, our call stack looks like this:

and the output so far is:

1
2

Now we encounter the longTaskFunc() (line 15) and it runs a time-consuming loop, effectively blocking our call stack for a significant duration due to JavaScript’s synchronous execution. That means the longTaskFunc() causes the bottleneck holding up the entire call stack, effectively delaying the subsequent functions, in our case second(), from executing until it completes.

Once longTaskFunc() finishes its long process, it logs Long Task Function and is popped off from the call stack, then paving the way for the remaining functions.

This behaviour emphasises the challenges of managing performance in synchronous, single-threaded environment. Such blocking operations on the main thread can lead to perceived performance issues giving users the impression of an unresponsive application or webpage.

Engineers often tackle such problems with asynchronous patterns like callbacks, promises or the async/await syntax. These methods can ensure tasks like longTaskFunc() don’t block the main thread, allowing for smoother user experience.

So how can we do async?

JavaScript, known for its synchronous and single-threaded execution, also handles multiple tasks asynchronously. This behaviour ensures that JavaScript doesn't get bogged down waiting for time-consuming tasks, like data fetching, to complete. Instead, it continues executing other tasks, returning to the completed ones when they're ready. But how does JavaScript achieve this with its synchronous nature?

This capability is part of the JavaScript runtime environment, a system that extends beyond the JavaScript engine itself. When JavaScript runs in a browser, for instance, this environment comprises not just the engine (like V8 in Chrome or SpiderMonkey in Firefox) that processes your JavaScript code, but also a range of Web APIs provided by the browser, the event loop, and a call stack.

As discussed above, the call stack is where function calls are placed when they are called and executed in order. However, synchronous JavaScript on its own could lead to performance issues: a long-running task could block the stack, making the web page unresponsive as we saw above.

This is where the Web APIs come into play. These are browser-provided features, separate from the JavaScript engine, that handle tasks like AJAX requests, setting timers, and much more. When a function like setTimeout() or an AJAX request using fetch() is called, the task is handled not by the JavaScript engine but by these Web APIs. Once these tasks complete, instead of going back directly to the call stack, they move to a (micro) task queue.

Now, the Event Loop enters the picture. Its primary role is to monitor the call stack and the (micro) task queue. If the call stack is empty (except GEC) and there are tasks in the queue waiting to be executed, the event loop takes these tasks and places them onto the call stack. This seamless coordination allows JavaScript to handle asynchronous operations effectively, enabling non-blocking tasks. The completion of an asynchronous task, like data fetching, triggers a callback function, which is then placed on the call stack by the event loop.

Through the combination of the JavaScript engine, Web APIs, the event loop, and the call stack, JavaScript's runtime environment can efficiently process tasks asynchronously. This design enables JavaScript to perform other operations without waiting for the completion of tasks, thus enhancing performance and user experience in web applications.

What's in Part 3?

In part 2, we have learnt about the execution context and how it stacks up in the call stack. Additionally, we also briefly touched on async operations in the JavaScript Runtime Environment.

In part 3 & 4, we will be deep diving into each component of JavaScript Runtime Environment including:

Web APIs
Event Loop
Task Queue
Microtask Queue
Animation Frame Queue

and understand how the Concurrency model operates in JavaScript.