← All issues

[JSC] Implement `%RegExpStringIteratorPrototype%.next` in C++

1452a43

JSC's DFG and FTL tiers inline frequently called builtins as first-class IR nodes, letting the compiler reason about types and elide JS call overhead. The "primordial exec" guard is a watchpoint: when RegExp.prototype.exec is still the original native implementation, the fast path calls execInline directly, bypassing the observable JS exec call. If exec is ever replaced — even mid-iteration after the call site has tiered up — the watchpoint fires and JSC must OSR-exit to the slow path.

JSTests/stress/regexp-string-iterator-next-adversarial.js

+ class Species extends RegExp {
+ static get [Symbol.species]() {
+ return function (p, f) {
+ matcher = new RegExp(p, f);
+ if (configure)
+ configure(matcher);
+ return matcher;
+ };
+ }
+ }

This commit migrates %RegExpStringIteratorPrototype%.next from a JavaScript builtin (now deleted) to a native C++ implementation, adding a new RegExpStringIteratorNext DFG node compiled inline in both DFG and FTL tiers, with a fast path that calls RegExpObject::execInline directly when the iterated RegExp still holds the primordial exec.

Every String.prototype.matchAll loop now routes through a new JIT-inlined C++ hot path with watchpoint-gated fast/slow branching, yielding up to ~19% throughput improvement on matchAll benchmarks.

🔒

New DFG/FTL inline node with watchpoint-gated fast path and inlined object allocation — several edge cases in the fast/slow path transitions are worth investigation.

Subscribe to read more