JavaScript Execution Model: Contexts, Realms, Jobs & Agents

Advanced

ECMAScript describes runtime execution with specification-level machinery: Environment Records, execution contexts, Realms, Jobs, agents, and host hooks. These concepts explain what the language model needs to track without pretending that the specification is a browser event-loop implementation.

1. Execution contexts

An execution context is a specification device that tracks the evaluation of executable code. The running context is the top of the execution-context stack for its agent. Function calls can push a new context while the caller's evaluation is suspended.

Execution context stack

A function call creates a new execution context while the caller is suspended.

Context state follows evaluation

The execution context records the state needed to suspend and resume evaluation.

Environment records are not JavaScript objects

Environment Records are specification mechanisms used to model identifier bindings; programs cannot access them directly.

Lexical environments connect to outer environments

Nested lexical scopes are represented by Environment Records linked through an outer-environment relationship.

The current Realm belongs to the running context

An execution context has a Realm component describing the ECMAScript resources used by its code.

Realms have their own intrinsics

A Realm provides its own set of ECMAScript intrinsics; a value from another Realm can have a different intrinsic identity.

Promise reactions become Jobs

Promise reactions are scheduled as Jobs; they do not run in the middle of the current synchronous evaluation.

Jobs run one at a time in an agent

ECMAScript requires that only one Job be actively evaluated at a time within an agent.

A Job runs to completion

Once a Job begins, another Job cannot start until that Job finishes.

Agent is broader than one call stack

An agent contains execution contexts, the execution-context stack, a running context, an Agent Record, and an executing thread.

Agents and SharedArrayBuffer

Shared memory introduces interactions between agents, while the ECMAScript memory model defines the allowed observations.

Agent clusters group agents

The specification models agent clusters to describe which agents may share memory and related synchronization relationships.

Forward progress

An unblocked agent must eventually make evaluation progress under the specification's forward-progress requirements.

Active ScriptOrModule

Execution contexts carry ScriptOrModule information so the specification can identify the originating Script or Module during evaluation.

Realm and callback execution

A callback invoked from a Job gets an execution context associated with the relevant Realm; the host supplies the surrounding scheduling machinery.

Keep ECMAScript separate from the host event loop

ECMAScript defines contexts, Jobs, agents, and host hooks; a browser or Node.js host supplies its own scheduling environment.

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

Ownership boundaries

This lesson owns the ECMAScript runtime model. Scope and closures continue to own lexical binding behavior; Promises own Promise semantics; SharedArrayBuffer and Atomics own shared-memory operations; Scripts and Modules own module linking and evaluation; the future browser phase owns browser-specific event-loop and task integration. Those topics are referenced here only where the execution-model boundary requires them.

Authoring rules

Do not use the ECMAScript execution model as a synonym for a browser event loop. Treat Environment Records and execution contexts as specification mechanisms. Remember that host scheduling is partly defined through host hooks. When reasoning about asynchronous behavior, distinguish ECMAScript Jobs from browser tasks and rendering work.