Execution context and execution stack example explanation in JavaScript

JavaScript - Principles Series

In daily development, whenever we take over an existing project, we always like to take a look at the code written by others first. Whenever we see someone write cool code, we always sigh! How did you develop the talent to write such beautiful and concise code?

How can I reach the same level as the big guys? Okay, without further ado, let’s get into today’s topic.

1. Execution Context

In short, [Execution Context] is an abstract concept of the environment in which JavaScript code is parsed and executed. Any code running in JavaScript runs in its execution context.

When running JavaScript code, whenever you need to execute code, the code will first enter an environment (browser, Node client), then an execution context will be created for the environment, which will do some preparation before you run the code, such as determining the scope, creating global and local variable objects, etc.

Classification of execution contexts

Global Execution Context:

This is the default, most basic execution context. Code that is not in any function is in the global execution context.

It does two things:

Create a global object. In the browser, this global object is the window object.

Set the this pointer to point to the global object. There can only be one global execution context in a program.

Function execution context:

Each time a function is called, a new execution context is created for that function. Each function has its own execution context, but it is only created when the function is called. There can be any number of function execution contexts in a program. Whenever a new execution context is created, it executes a series of steps in a specific order, which will be discussed later in this article.

Eval function execution context:

The code running in the eval function also gets its own execution context, but since JavaScript developers don't often use the eval function, it won't be discussed here.

Limit on the number of execution contexts (stack overflow)

There can be multiple execution contexts. Although there is no clear limit on the number, if the space allocated by the stack is exceeded, a stack overflow will occur. This is common in recursive calls where there is no termination condition, resulting in an infinite loop.

Here is the sample code:

// Recursively calling itself function foo() {
  foo();
}
foo();
// Error: Uncaught RangeError: Maximum call stack size exceeded

Tips:

JS is "single-threaded", only executing one piece of code at a time

2. Execution Stack

The execution stack in JS, also known as the "call stack" in other programming languages, is a stack with a LIFO (last in, first out) data structure that is used to store all execution contexts created when the code is running.

When the JavaScript engine first encounters your script, it creates a global execution context and pushes it onto the current execution stack. Whenever the engine encounters a function call, it creates a new execution context for that function and pushes it on the top of the stack.

The engine executes the function whose execution context is at the top of the stack. When the function finishes executing, the execution context is popped from the stack and the control flow reaches the next context in the current stack.

Stack Data Structure

Now let's use a piece of code to understand the execution stack

let a = 'Hello World!';

function first() {
 console.log('Inside first function');
 second();
 console.log('Again inside first function');
}

function second() {
 console.log('Inside second function');
}

first();
console.log('Inside Global Execution Context');

The following figure is the execution stack of the above code

When the above code is loaded in the browser, the browser's JavaScript engine will create a global execution context and push it into the current execution stack. When a function call is encountered, the JavaScript engine creates a new execution context for the function and pushes it on top of the current execution stack.

When the second first() second() function, the JavaScript engine creates a new execution context for second() function and pushes it on top of the current execution stack. When second() function is finished executing, its execution context is popped off the current stack and the control flow reaches the next execution context, which is the execution context of the first() function.

When first() finishes executing, its execution context is popped from the stack and control flows to the global execution context. Once all code is executed, the JavaScript engine removes the global execution context from the current stack.

The Creation Phase

Before JavaScript code is executed, the execution context goes through a creation phase. Three things happen during the creation phase:

The determination of this value is known as This binding.
Creates a LexicalEnvironment component.
Create a variable environment component.

So the execution context is conceptually represented as follows:

ExecutionContext = {
 ThisBinding = <this value>,
 LexicalEnvironment = { ... },
 VariableEnvironment = { ... },
}

This binding:

In the global execution context, the value of this refers to the global object. (In a browser, this refers to the Window object).

In the context of a function execution, the value of this depends on how the function is called. If it is called with a reference object, then this is set to that object, otherwise the value of this is set to the global object or undefined (in strict mode). For example:

let foo = {
 baz: function() {
 console.log(this);
 }
}
foo.baz(); // 'this' refers to 'foo', because 'baz' is called // on the object 'foo' let bar = foo.baz;
bar(); // 'this' refers to the global window object because // no reference object is specified

Lexical Environment

The official ES6 documentation defines a lexical environment as

A Lexical Environment is a specification type that defines the association of identifiers with specific variables and functions based on the lexical nesting structure of ECMAScript code. A Lexical Environment consists of an Environment Recorder and a possibly empty value that refers to an outer Lexical Environment.

In simple terms, a lexical environment is a structure that holds identifier-variable mappings. (Here identifier refers to the name of the variable/function, while variable is a reference to the actual object [including function type objects] or primitive data).

Now, inside a LexicalEnvironment there are two components: (1) an EnvironmentRecordant and (2) a reference to the outerEnvironment.

The environment recorder is the actual location where variable and function declarations are stored.
A reference to the outer environment means that it has access to its parent Lexical Environment (scope).

There are two types of Lexical Environments:

The global environment (in the global execution context) is a Lexical Environment that has no outer environments referenced. The global environment's outer environment reference is null. It has built-in Object/Array/etc, prototype functions in the environment recorder (associated with the global object, such as the window object) and any user-defined global variables, and the value of this refers to the global object.
In a function environment, user-defined variables inside a function are stored in the environment recorder. The outer environment referred to may be the global environment, or any outer function that contains this inner function.

There are also two types of environment loggers (as above!):

Declarative environment recorders store variables, functions, and parameters.
The object environment recorder is used to define the relationship between variables and functions that appear in the global context.

in short

In the global environment, the environment logger is the object environment logger.
In a function environment, the environment logger is a declarative environment logger.

Notice

For function environments, the declarative environment recorder also contains an arguments object passed to the function (this object stores a map of indices and parameters) and the length of the arguments passed to the function.

Abstractly, a Lexical Environment looks like this in pseudocode:

GlobalExectionContext = {
 LexicalEnvironment:
  EnvironmentRecord: {
   Type: "Object",
   // bind identifier here }
  outer: <null>
 }
}

FunctionExectionContext = {
 LexicalEnvironment:
  EnvironmentRecord: {
   Type: "Declarative",
   // bind identifier here }
  outer: <Global or outer function environment reference>
 }
}

Variable environment:

It is also a Lexical Environment whose Environment Recorder holds the bindings created by variable declaration statements in the execution context.

As mentioned above, a variable environment is also a lexical environment, so it has all the properties of a lexical environment defined above.

In ES6, one difference between the LexicalEnvironment component and the VariableEnvironment is that the former is used to store function declarations and variable ( let and const ) bindings, while the latter is only used to store var variable bindings.

Let's look at some sample code to understand the above concepts:

let a = 20;const b = 30;var c;
function multiply(e, f) { var g = 20; return e * f * g;}
c = multiply(20, 30);

The execution context looks like this:

GlobalExectionContext = {

 ThisBinding: <Global Object>,

 LexicalEnvironment:
  EnvironmentRecord: {
   Type: "Object",
   // Bind identifier a here: < uninitialized >,
   b: < uninitialized >,
   multiply: < func >
  }
  outer: <null>
 },

 VariableEnvironment: {
  EnvironmentRecord: {
   Type: "Object",
   // Bind identifier c here: undefined,
  }
  outer: <null>
 }
}

FunctionExectionContext = {
 ThisBinding: <Global Object>,

 LexicalEnvironment:
  EnvironmentRecord: {
   Type: "Declarative",
   // Bind identifiers here Arguments: {0: 20, 1: 30, length: 2},
  },
  outer: <GlobalLexicalEnvironment>
 },

VariableEnvironment: {
  EnvironmentRecord: {
   Type: "Declarative",
   // Bind identifier g here: undefined
  },
  outer: <GlobalLexicalEnvironment>
 }
}

Notice

The function execution context is created only when the function multiply is called.

You may have noticed that variables defined with let and const have no values associated with them, but variables defined with var are set to undefined .

This is because during the creation phase, the engine inspects the code to find variable and function declarations, and while function declarations are completely stored in the environment, variables are initially set to undefined (in the case of var ) or uninitialized (in the case of let and const ).

This is why you can access a variable defined with var before declaration (although it is undefined ), but you will get a reference error when accessing a variable defined with let or const before declaration.

This is what we call variable declaration hoisting.

Execution Phase

This is the easiest part of the whole article. At this stage, assignments to all these variables are done and finally the code is executed.

Notice

During the execution phase, if the JavaScript engine cannot find the value of the let variable at the actual location where it is declared in the source code, it will be assigned the value undefined .

in conclusion

We have already discussed how JavaScript programs are executed internally. Although you don’t need to learn all of these concepts to become an excellent JavaScript developer, having a good understanding of the above concepts will help you understand other concepts such as variable declaration hoisting, scope, and closures more easily and in depth.

Reference articles:

https://juejin.cn/post/6844903682283143181

https://www.jianshu.com/p/6f8556b10379

https://juejin.cn/post/6844903704466833421

This is the end of this article about the execution context and execution stack examples in JavaScript. For more information about the execution context and execution stack in JavaScript, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!

You may also be interested in: