← All issues

[JSC] MapIterator / SetIterator should be handled in DFG

300fd8c

// Source/JavaScriptCore/builtins/MapIteratorPrototype.js: Removed.
// Source/JavaScriptCore/builtins/SetIteratorPrototype.js: Removed.
+ JSC::VM::fastMapKeysSentinel
+ JSC::VM::fastMapValuesSentinel
+ JSC::VM::fastSetEntriesSentinel
+ JSC::iteratorOpenTryFastImpl
+ JSC::iteratorNextTryFastImpl

JSC's DFG performs speculative optimizations based on observed types. 'Handling an iterator in DFG' means emitting IteratorOpen and IteratorNext IR nodes that lower directly to C++ fast-path calls instead of dispatching through JS function call machinery. The fast path is protected by watchpoints — weak references that fire and trigger OSR-exit when guarded objects (here, MapIteratorPrototype.next or Map.prototype[@@iterator]) are modified.

This commit moves MapIterator#next() and SetIterator#next() from builtin JavaScript to C++ and wires all six Map/Set iteration methods into DFG as first-class fast paths. The VM now carries three new sentinel values (fastMapKeysSentinel, fastMapValuesSentinel, fastSetEntriesSentinel) used to distinguish iteration modes. Previously next() ran through JS-level safety guarantees; moving to C++ with DFG integration eliminates that safety net — the C++ implementation must manually uphold every invariant the JS version got for free.

This is a large-surface JIT fast-path addition: new C++ iterator state machines, new DFG IR nodes, new watchpoint guards, and new cross-realm checks all land at once. Every layer is a potential source of type confusion, lifetime bugs, or guard-bypass.

🔒

New JIT-generated code for security-critical iterator operations — several edge cases in the fast path and its guards are worth audit investigation.

Subscribe to read more