V8中不同Context的内存隔离及多Context内存布局疑问

Hey there! As someone just getting into Chromium and V8, it makes total sense to wonder about how Contexts handle memory and isolation—let’s break this down clearly:

1. What are the memory boundaries between Contexts? #

V8’s Contexts enforce isolation primarily through scope and object ownership:

• Global Object Isolation: Each Context has its own unique global object (like window in browser frames). Variables and functions attached to this global object are only accessible within that Context, unless explicitly shared via cross-context APIs (like postMessage in browsers).
• Built-in Object Instance Isolation: Core built-ins (like Array, Object, or Date) are not shared across Contexts. A new Array() created in Context A is an instance of Context A’s Array constructor, and can’t be used with Context B’s Array.prototype methods directly.
• Enforced Access Checks: V8 tags every object with its originating Context. If code in one Context tries to access an object from another without proper bridging, V8 blocks the operation (or throws a security error, depending on the environment).

2. Do individual Contexts have their own stacks and heaps? #

Great question—this is a common point of confusion:

• Stack: No, the stack is tied to the Isolate, not individual Contexts. An Isolate corresponds to a single thread’s execution stack. When JS runs, the call stack (including execution contexts for functions) lives on this shared Isolate stack. The current Context is just a piece of metadata attached to the top of the execution stack.
• Heap: The main V8 heap is shared across all Contexts in an Isolate, but with key isolation safeguards:
  • Each Context has its own set of built-in object instances (like Array.prototype, Object.prototype) stored in the heap, marked with their Context’s identifier.
  • Variables and objects created within a Context are tagged with that Context’s ID. This lets V8 perform Context-specific garbage collection—for example, when a browser tab closes, V8 can efficiently collect all objects tied to that tab’s Context without scanning the entire heap.
  • The variable environment (let/const declarations, function scopes) for each Context is stored in heap-allocated context objects, isolated from other Contexts’ environments.

3. How does V8 maintain and switch between Contexts? #

V8 manages Contexts as lightweight state containers, and switching is straightforward but intentional:

• Context Maintenance: Each Context is a C++ object (v8::Context) that holds references to its global object, built-ins, security settings, and execution state. V8 keeps track of all active Contexts in an Isolate, but only one is marked as "current" at any time.
• Switching Mechanism:
  • At the C++ level, you switch Contexts using isolate->SetCurrentContext(new_context). This updates the Isolate’s internal pointer to the active Context.
  • In browser environments (like Chromium), switching between tabs or iframes triggers this under the hood—when you interact with an iframe, the renderer thread switches to that iframe’s Context.
  • When switching, the current call stack isn’t cleared, but any subsequent JS execution will use the new Context’s global scope and built-ins. V8 checks the active Context on every key operation (like resolving a variable name or creating an object) to ensure isolation.
• Performance Optimizations: V8 caches Context-specific data (like built-in method pointers) to minimize overhead when switching. Since Contexts are lightweight, switching between them is fast—no expensive stack/heap copying is involved.

内容的提问来源于stack exchange，提问作者Wu Luo