JavaScript生成器栈模型实现疑问：Chrome与Firefox引擎如何处理？

Great question! This is one of those under-the-hood details that makes generators (and async/await, which are built on them) so powerful. Let’s break down how Chrome’s V8 and Firefox’s SpiderMonkey handle this magic.

V8 (Chrome, Edge, Node.js) #

In normal function calls, V8 uses a traditional call stack where each function’s execution frame lives on the stack. When a function returns, its frame is popped off the stack and memory is reclaimed—simple LIFO behavior.

Generators throw a wrench into this because they need to pause execution and resume later without losing their state. Here’s how V8 solves it:

• Heap-allocated generator frames: Instead of keeping the generator’s execution frame on the call stack, V8 allocates it on the heap. This frame (called a GeneratorObject) stores everything needed to resume execution later: local variables, the current position in the code (via a program counter/PC pointer), the lexical environment, and any pending return values.
• Pausing process: When a generator hits a yield statement, V8 "unwinds" the generator’s frame from the call stack but doesn’t destroy it—instead, it moves the entire frame to the heap. The generator object itself acts as a reference to this heap frame.
• Resuming process: When you call generator.next(), V8 takes that heap-allocated frame and pushes it back onto the call stack. It restores all the saved state (local variables, execution position) and picks up right where the yield left off.

This is why generators can be paused and resumed multiple times—their state lives in the heap, not the ephemeral call stack. Async/await uses exactly the same mechanism under the hood, with extra logic to handle Promises.

SpiderMonkey (Firefox) #

SpiderMonkey’s approach is conceptually similar, with a few terminology differences:

• GeneratorFrame: This is the heap-allocated structure that holds the generator’s state. Like V8’s GeneratorObject, it stores local variables, execution position, and context.
• Unwinding and restoring: When a generator pauses at a yield, SpiderMonkey unwinds the frame from the call stack but preserves its state in the GeneratorFrame on the heap. When next() is called, the frame is re-pushed onto the stack, and execution resumes from the saved position.
• Optimizations: SpiderMonkey has some tricks to minimize overhead—for example, if a generator is resumed quickly after pausing, it might avoid fully moving the frame to the heap and instead keep it in a temporary buffer. But the core idea of heap-stored state remains the same.

Why Not Use the Regular Call Stack? #

The regular call stack is designed for functions that run to completion. Once a frame is popped off the stack (when a function returns), its memory is reclaimed immediately. Generators need to hold onto their state indefinitely until they’re either exhausted or garbage collected—something the stack can’t handle because it’s a fixed-size, LIFO structure. Heap allocation lets the engine preserve the generator’s state outside the call stack, making pause/resume possible.

To put this in concrete terms, take this simple generator:

function* counter() {
  let count = 0;
  while (true) {
    yield count++;
  }
}

const gen = counter();
console.log(gen.next().value); // 0
// The generator's state (count = 0, execution position at the yield) is stored on the heap
console.log(gen.next().value); // 1
// State is restored, count increments, yield returns 1

Every time you call gen.next(), the engine pulls the saved frame from the heap, restores it, and continues execution.

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