[sebastienros]

Every regular expression written in script now runs on the ECMAScript flavor of GregsEx. Jint previously ran most patterns by converting them to .NET Regex, and the rest on a QuickJS libregexp port. Both are removed.

The full record — the decision, what changed, what the work found in either project, and the benchmarks — is in docs/design/regexp-gregsex-migration.md.

How GregsEx is consumed

Referencing the package is not an option: it ships net10.0 only, and its public surface stops above what a JavaScript engine needs (group names before a match, and an executor below the lastIndex session). The ECMAScript closure is vendored instead:

• Where it lives: about 9.6K lines plus the Unicode 17.0 tables, under Jint/Runtime/RegExp/GregsEx/. All of it is internal.
• How it is produced: tools/sync_gregsex.py regenerates the folder from GregsEx main. It applies mechanical transforms (namespace, internal, #nullable enable), then tools/gregsex-sync/jint.patch.
• What the patch holds: structural edits only — the trimmed LaneContracts, only the Unicode 17.0 tables, and the .NET 9 SearchValues<string> lanes with their downlevel fallbacks. Every behavioural fix went upstream.
• Keeping it current: .github/workflows/gregsex-sync.yml regenerates the folder every Monday. If the diff is empty it stops; otherwise it builds every target framework, runs the regex tests and opens a pull request.

Upstream fixes

The defects this work found in GregsEx were fixed there first, each pinned by a test on both sides:

• sebastienros/gregsex#2 — correctness and the first speedups:

  • lone surrogates in the literal plans;
  • quantifier bounds above int.MaxValue;
  • an overflow in the atomic-sequence plan;
  • a greedy single-character run kept in one counted choice;
  • the case-insensitive and nullable-prefix prefilters;
  • timed budgets.

  It also made GregsEx #nullable enable throughout.

• sebastienros/gregsex#3 — the second pass, after the first paired run:

  • per-search VM frame setup;
  • a clock read per search;
  • nullable repeats on the atomic-sequence plan;
  • case-insensitive classes and literals;
  • FIRST-character prefilters through groups;
  • line-terminator scans.

  It also fixes an inverse-fold cache that was shared across Unicode versions.

Breaking changes

Documented in docs/guide/migrating-to-v5.md §2, §4.161 and §5.42:

• Removed: JsRegExp.Value, JsRegExp.ParseResult, and CompileRegex on the parsing options. A script RegExp now converts to the CLR as the JsRegExp itself.
• Host Regex objects keep the semantics they had. A Regex the host hands to script keeps .NET semantics, as before. The new escape hatch Options.Interop.RegexConversion = RegexConversionMode.EcmaScript converts it to an ECMAScript pattern instead.

Compliance

Suite	main	this branch
test262 (7ab7fafa, all five sub-directories, both modes)	102,653 passed, 0 failed, 87 skipped	102,653 passed, 0 failed, 87 skipped
GregsEx ECMAScript corpora against their Node 24.4.1 / V8 13.6 oracle	2,342 of 2,346	2,342 of 2,346 (the same four failures)
Jint.Tests, Jint.Tests.PublicInterface, Jint.Tests.CommonScripts	all pass	all pass, with 71 new cases in RegExpEngineRegressionTests

None of the 87 skipped test262 cases is regex-related, and the harness settings exclude nothing regex-related, so there was no skipped regex corpus to re-enable. The four corpus failures are the same on both builds:

• three cases of /./uy with lastIndex inside a surrogate pair, which GregsEx's corpus marks as disputed;
• one harness artefact (String(-0)).

Performance

Paired BenchmarkDotNet run (Jint.Benchmark/measure-paired.ps1, 3 rounds in alternating order) of every regex benchmark the suite has, plus SunSpider regexp-dna and Dromaeo ObjectRegExp:

• Builds compared: main at 82b0efbaa against this branch with GregsEx dc455e97 vendored.
• Machine: Apple M4 Pro, .NET 10.0.11, macOS 15.
• Reading it: a row counts as a change only when its 95% CI excludes zero. control-indexOf never reaches regex code; it reads +0.9% [+0.1, +3.0], the run's noise floor. Three rounds settles the large effects; a ±5% row needs six.

36 of the 41 rows are faster; 4 are slower.

Row	Δ vs main	95% CI
template-replace-g (str.replace(/(a)(b)?/g, '$2$1'))	−97.9%	[−98.0, −97.8]
SplitUnicode	−92.1%	[−92.2, −92.1]
uprop-match-g (/\p{L}+/gu)	−92.0%	[−92.2, −92.0]
VariableLength	−83.8%	[−83.9, −82.8]
SunSpider regexp-dna	−73.5%	[−74.4, −72.8]
FreshEngineSource	−73.0%	[−73.5, −71.2]
SplitWithCaptures	−59.9%	[−60.0, −59.0]
capture-match-g	−50.9%	[−51.9, −48.3]
NamedCapture	−46.3%	[−46.3, −45.7]
class-match-g	−45.4%	[−45.5, −44.7]
GlobalMatchAll / IsMatchOnly / LiteralScan	−40.5% / −40.2% / −38.2%	all exclude zero
MatchGlobalUnicode / MatchGlobal	−39.2% / −31.9%	all exclude zero
nullable-split (csv.split(/\s*,\s*/))	−35.6%	[−38.5, −34.4]
NoMatchScan	−34.9%	[−35.9, −34.3]
greedy-dotstar-exec / -test (/a.*a/ over 64 KiB)	−30.3% / −27.1%	all exclude zero
construct-100 / function-replace-g / CaseInsensitiveScan	−26.9% / −26.1% / −25.7%	all exclude zero
char-split (str.split(/a/))	−21.9%	[−24.1, −20.9]
exec loops (NamedGroupsAccess, MatchAllIterate, ExecWhileLoop, exec-loop, StickyExec)	−21.2% … −16.4%	all exclude zero
RegExpSplitBenchmark.Split	−10.2%	[−10.6, −9.1]
Dromaeo ObjectRegExp (4 rows)	−10.0% … −7.9%	all exclude zero
FreshEnginePrepared	−6.5%	[−15.0, −6.4]
CharClassScan / DigitScan	−2.9% / −2.0%	all exclude zero
Slower: AnchoredLiteral	+50.6%	[+49.1, +61.8] — 13 ns → 19 ns
Slower: literal-test / literal-replace-g	+17.6% / +15.6%	3.2 µs → 3.7 µs / 3.3 µs → 3.8 µs
Slower: icase-literal-test	+4.7%	[+4.5, +5.7], below the three-round bar

Allocation fell on the capture-heavy rows:

Row	Before	After (per operation)
template-replace-g	177 MB	0.6 MB
SplitUnicode	25 MB	1.6 MB
capture-match-g	10.5 MB	2.3 MB
MatchGlobal	5.8 MB	1.4 MB

The literal rows scan 64 KiB for a 10-character literal that isn't there. GregsEx already uses the fastest search I measured for that (SearchValues<string>: 3.1 µs, against 4.9 µs for IndexOf(string)). .NET Regex chooses its anchor characters from a frequency table, which is what the remaining 0.5 µs would take.

The baseline is main from before the latest merge. The only regex change on main since then (#4267) touched the removed QuickJS interpreter. Its new surrogate-pair tests in RegExpTests run against GregsEx here.

Follow-ups

These are listed in the design doc's §6:

• the literal-scan anchor choice;
• batching global match and plain-string replace the way split now is;
• a parse-time validator on the GregsEx parser, so a literal is no longer parsed twice;
• moving String.prototype.toUpperCase/toLowerCase onto the GregsEx Unicode tables;
• the legacy RegExp.$1 statics in the fused lanes.

🤖 Generated with Claude Code

[lahma]

Sebastien, this is a careful migration: test262 holds at zero failures, the fused lanes keep the spec's order, and the timeout still surfaces as RegexMatchTimeoutException. I'd hold the merge for the first finding below. The others are smaller and mostly a question of documenting what changed for embedders.

Everything here comes from reading the PR head (ebe97e074) against main; I haven't built or run it, so the sizes below are arithmetic from the code, not measurements.

1. Backtracking scratch grows to gigabytes, is shared across engines, and is never released

• Per-frame cost. Every choice point reserves a full copy of the task stack plus the registers.
  • Reservation: EcmaExecutor.GetRequiredCapacity (EcmaExecutor.cs:55-65) and Save (:860-894).
  • Per frame that is 6 × (2·depth + 4) + 2·groups + 4 ints (EcmaExecutorFactory.cs:56-57).
  • A greedy repeat over a multi-character body, and every alternative, saves one frame per iteration (EcmaExecutor.cs:467-473, :532-539).
• Ceiling. Plans grow ×4 up to MaxFrames = 1 << 22 (JintRegExpEngine.cs:43, :316-323).
• Example. /"(?:[^"\\]|\\.)*"/, an ordinary string-literal tokenizer, over a ~1 MB literal needs about 100 ints per frame at two frames per character. That is ~0.4 GB at the 1M-frame plan and ~1.7 GB at 4M. The QuickJS port capped its stack at 16M ints (64 MB).
• Shared across engines. The grown FramePlan is published onto the JintRegExpEngine itself (Volatile.Write(ref _plan, …)).
  • That instance is cached process-wide (RegExpParseCache.cs:28) and memoised on AST nodes (JintLiteralExpression.cs:80-86).
  • Search requires every thread's scratch to fit the grown plan (:269-272).
  • So after one large input, every thread and engine that later runs the same pattern, even on a three-character subject, allocates the full buffer.
• Never released. t_scratch only grows (:355-370), so the memory stays for the life of the thread.
• Constraints can't prevent it. LimitMemory can only object after the native call has allocated. The regex timeout doesn't prevent the allocation either.
• Overflow. Past taskSlots ≥ 512, or groups ≥ 256 at 4M frames, the checked arithmetic in GetRequiredCapacity throws a raw OverflowException. #4240 just lifted the 255-group limit, so that second case is now reachable.
• Fix:
  • Bound the scratch by bytes, not frames; the old 64 MB is a reasonable figure.
  • Above a small threshold, allocate per search and drop the buffer afterwards, rather than keeping it in t_scratch.
  • Don't publish growth onto the shared matcher.
  • Upstream, variable-length frames (store used ints rather than reserving taskSlots per frame) would cut this by an order of magnitude.

The design doc and the comment in JintLiteralExpression describe the matcher as immutable; _plan makes that untrue.

2. Exhausting the frame ceiling throws an internal exception

• SearchSlow throws RegExpResourceException (JintRegExpEngine.cs:318, class at :411).
  • It's internal and derives from Exception.
  • Nothing catches it, and it isn't in Throw.MustPropagateHostException.
• The QuickJS port threw RegexMatchTimeoutException("Regular expression backtracking stack overflow"). V8 throws a RangeError.
• So an embedder now receives a type they can't name, with no migration entry.
• Fix: map exhaustion, and the OverflowException path from finding 1, to a JS RangeError, or keep RegexMatchTimeoutException. Add a row to the guide.

3. Interop changes the migration guide doesn't spell out

§4.161 says ToObject() and "every conversion built on it" now return the JsRegExp. In practice that means:

• CLR binding. A script RegExp no longer binds to a Regex-typed method parameter, property or delegate.
  • Binding goes through argument.ToObject() (MethodInfoFunction.cs:459), which now yields the JsRegExp.
  • DefaultTypeConverter has no Regex case.
  • So host.Use(/a/) with string Use(Regex r) stops resolving.
• Engine-bound objects in host graphs. ToObject() on { re: /x/ } now puts an engine-bound JsRegExp into the host's ExpandoObject or dictionary.
  • It exposes ObjectInstance.Engine to any serializer that walks public properties.
  • A host that hands results from one engine to another now moves a JsValue across engines, which is unsupported.
• No way to match from C#. The guide says "read Source/Flags" but doesn't say how a host can still match. Either engine.Invoke on exec, or a best-effort new Regex(source, …), would do.
• The public JsRegExp(Engine) constructor can no longer be made usable, since Value and ParseResult are gone. The guide could point to Intrinsics.RegExp.Construct.

4. search stopped updating RegExp.$1

• On main, a non-u pattern in RegExp.prototype[@@search] went through RegExpExec, and so through UpdateLegacyStaticProperties.
• Now every script pattern takes the fused lane (RegExpPrototype.cs:1478-1488), which doesn't update the statics.
• So 'zzq'.match(/(z)/); 'xaby'.search(/(a)(b)/); RegExp.$1 gives "a" on main and "z" here.
• J3 in the design doc calls the fused-lane gap pre-existing and unchanged; that's true for the other lanes but not for search.
• FusedReplace, by contrast, now sets the statics from the last match before any replacer runs, which is better than main.

5. Cold compile cost and memory per compiled pattern

• Bitmap per node. Every set node gets its own EcmaFastSet with an 8 KiB ulong[1024] bitmap (EcmaAccelerator.cs:66, :671). That covers ., […], \d, \w and \s, and it is per node, not per distinct set.
• Legacy i loop. Under legacy i, each set also loops over all 65,536 BMP code units (:158-173).
• Case-mapping set. An i pattern that contains a cased literal builds a HashSet of roughly 2,500 case mappings on every compile (:607-639).
• Not measured. None of this shows in the suite, because every compile row hits the process cache after warm-up. construct-100 uses only 10 distinct sources. A cold-compile row with a few hundred distinct patterns, i classes among them, would show whether it matters.
• Fix:
  • Share EcmaFastSet instances for identical sets, at least within a program.
  • Build a bitmap only for sets with non-ASCII members.
  • Walk the bitmap's words instead of all 65,536 code units.
  • Cache the cased-character set the way InverseFolds is cached.

6. gregsex-sync.yml runs fetched upstream code with a write token

• The workflow grants contents: write and pull-requests: write workflow-wide.
• actions/checkout persists GITHUB_TOKEN in .git/config, and the same job then builds and runs tests over freshly downloaded upstream files and restored packages.
• Fix: a read-only build-and-test job with persist-credentials: false, then a second job, holding the write permissions, that applies the diff, pushes and opens the PR without running repo code.

Two smaller points in the same file:

• git push --force on gregsex-sync discards any commits someone pushed there, which the file's own header invites.
• The test filters miss HostRegexTimeoutTests, the URLPattern hostile-pattern test and test262's String.prototype regex tests.

7. Smaller items

• Stale agent docs. Jint/Constraints/AGENTS.md:67 and Jint/Runtime/Interpreter/AGENTS.md:22 still describe JintLiteralExpression.AdaptedRegExp, the compilation mode and the custom-engine split. RegexConversionOptions.ResolveTimeout is now dead code, and the comment at RegExpConstructor.cs:476 names a GetMatchTimeout that doesn't exist.
• Compiling a run-time pattern is no longer bounded.
  • main compiled for the custom engine under CancellationTokenSource(regexTimeout).
  • JintRegExpEngine.Compile is now called without a token, and CompileLimits sets every budget to MaxValue.
  • If GregsEx's compile is linear in the pattern this doesn't matter; if any stage isn't, a script-supplied new RegExp(src) is now unbounded.
• RegexConversionMode.EcmaScript.
  • It rejects RegexOptions.ECMAScript, the one .NET option that aligns the syntax.
  • It silently drops the host Regex's MatchTimeout.
  • §5.42 and the enum doc say an incompatible pattern throws "rather than matching differently". That isn't so: \d, \w, \b, $ and . are valid in both and match differently.
• Split timeout. A split on a pattern without groups shares one deadline across up to 32 searches (JintRegExpEngine.cs:168), so §4.161's "the timeout applies to every match" doesn't quite hold there.
• Downlevel.
  • The patch puts about ten #if NET9_0_OR_GREATER blocks inside EcmaAccelerator/EcmaExecutor. A Jint-owned wrapper, like the existing StringSearchValues, would keep the patch structural and less fragile on every sync.
  • The net8.0 asset runs those fallback lanes, and Jint.Benchmark is net10.0-only, so they have never been measured.
• Attribution. CREDITS.txt doesn't mention GregsEx (MIT) or the UCD 17 data.
• AOT. Jint.AotExample has no regex probe, so the native leg never exercises the new engine.

Gate rows (x64)

I'll run these in a quiet window once finding 1 is addressed.

• RegExpCustomEngineBenchmark.AnchoredLiteral, .CaseInsensitiveScan, .DigitScan, .CharClassScan
• RegExpShapeBenchmark.Run:
  • the slower rows: literal-test, literal-replace-g, icase-literal-test
  • the floor: control-indexOf
  • representative faster rows: template-replace-g, nullable-split, greedy-dotstar-test, char-split, function-replace-g, construct-100
• RegExpSplitBenchmark.Split, .SplitUnicode; RegExpMatchBenchmark.MatchGlobal; RegExpExecLoopBenchmark.ExecWhileLoop, .StickyExec
• RegExpFreshEngineBenchmark.FreshEngineSource, .FreshEnginePrepared
• SunSpiderBenchmark.Run: regexp-dna, string-tagcloud, string-unpack-code, string-validate-input, date-format-xparb
• DromaeoBenchmark.ObjectRegExp, all four Modern × Prepared rows
• Handlebars (PreparedScriptBenchmark): ExecuteStringOnMultipleEngines, and this PR's ExecutePreparedOnMultipleEngines against main's ExecutePreparedWithRegexCompilationOnMultipleEngines, which was renamed
• Non-regex controls: StringSplitBenchmark.SplitOnChar, StringReplaceBenchmark.ReplaceAllPattern, DromaeoBenchmark.ObjectString

[sebastienros]

Thanks, Marko, this was a very useful read. Everything that lives in this PR is fixed in 122bc7520. Two items need GregsEx changes; for one of them that work has started.

1. Backtracking scratch

• Bounded by size, not by frame count. The ceiling is computed from the pattern's own per-frame size, so GetRequiredCapacity can no longer overflow (including at high group counts).
• Retention: a thread keeps at most 1 MiB between searches. Growth beyond that belongs to the one search and is dropped when it returns.
• Sharing: only growth within that 1 MiB is published to the shared matcher, as a sizing hint. The docs now call it that, instead of claiming the matcher is immutable.
• Ceiling: a search may use at most 64 MiB, the QuickJS figure.
• Your example now throws. Your string-literal tokenizer over 1 MB hits that ceiling. main matched it, because QuickJS frames are smaller. The real fix is your variable-length-frames suggestion, which is GregsEx work I'm proposing upstream. Until then it's recorded in the migration guide and the design doc.

2. Exhaustion exception. Exhaustion now throws a JS RangeError ("Maximum regular expression backtracking depth exceeded"), as V8 does. The guide has a row for it.

3. Interop. §4.161 now covers:

• Regex-typed parameters, properties and delegates no longer binding;
• ToObject() graphs holding the engine-bound JsRegExp;
• matching from C# via exec, and the caveats of new Regex(source);
• Intrinsics.RegExp.Construct.

new JsRegExp(engine) now gets the empty pattern's matcher instead of none.

4. search statics. Fixed: search updates RegExp.$1… again. Your example now gives "a", the same as main, and is pinned. J3 in the design doc is corrected.

5. Cold compile. You were right, and it's worse than the arithmetic suggested. I added RegExpColdCompileBenchmark (50 unique patterns per operation, cache misses):

Row	vs main
email (no flags)	+55%
email-i	+1,225%
classes-i	+461%
\p{L} under u	+1,596%

Part of this is my own regression from sebastienros/gregsex#3: the folded-bitmap loop and the per-compile cased-character set. The rest predates it: property resolution in the compiler, and one 8 KiB bitmap per set node. All of it is GregsEx code. A GregsEx PR is in progress, and its numbers will come back here through the sync.

6. gregsex-sync.yml

• Jobs split: a read-only build-and-test job with persist-credentials: false hands its diff to a write job that runs no repository code.
• Branches: one branch per upstream revision, never force-pushed.
• Test filters: they now cover HostRegexTimeoutTests, URLPattern, and test262's String.prototype regex methods.

7. Smaller items

• Stale agent docs: both rewritten for the new design. ResolveTimeout is used again rather than deleted, and the stale GetMatchTimeout comment is fixed.
• Compile bound: compiling now runs under the regex timeout, converted to a GregsEx compile-work budget (GregsEx's compiler reads no clock). Running out throws RegexMatchTimeoutException.
• RegexConversionMode.EcmaScript: it accepts RegexOptions.ECMAScript, keeps the host Regex's MatchTimeout, and the docs now list \d, \w, \b, $ and . as matching differently.
• Split timeout: the guide now says a split takes its matches 32 at a time, with one deadline per batch.
• Attribution and AOT: CREDITS.txt lists GregsEx and UCD 17, and Jint.AotExample has a regex probe, its RangeError case included.
• Not done:
  • Moving the #if NET9_0_OR_GREATER blocks behind a Jint-owned wrapper. I'd rather fold that into the next sync than grow this PR.
  • Downlevel measurement, still unmeasured.
  • Legacy statics for the other fused lanes, still a follow-up.

All suites, test262 (102,653 / 0 failed), the docs build and its link check pass. Your gate list looks right; run it whenever you have a quiet window. I'd hold the merge for the GregsEx cold-compile PR so its fix lands with this one.

[lahma]

Thanks, Sebastien. I read 122bc7520 against the points I raised, and the fixes hold:

• Scratch growth. _maxFrames comes from the affine per-frame size, so GetRequiredCapacity stays far below int.MaxValue.
• Retention. Growth past RetainedScratchInts uses per-search arrays and is never published.
• Exhaustion error. Every FindRanges/exec catch site maps RegExpResourceException to RangeError. That includes URLPattern, which goes through RegExpBuiltinExec.
• Compile timeouts. A compile that runs out of budget is not cached (RegExpParseCache), so a short-timeout engine can't poison a pattern for a long-timeout one.

Two things remain, both from reading the code. I haven't run either.

1. The ceiling is reached at roughly 80K characters, not 1 MB.

• The tokenizer frame is about 100 ints, and the pattern needs two frames per character.
• So MaxScratchInts (16M ints) runs out at about 16M / 200 ≈ 84K characters.
• That means /"(?:[^"\\]|\\.)*"/ throws RangeError on any string literal longer than that. main matches it, and so does V8, whose backtrack stack holds millions of entries.
• The same applies to any (?:a|b)* over a long input, which is a common shape in markdown and template tokenizers.

Since the merge is already waiting for the GregsEx cold-compile PR, I'd like variable-length frames to land with it. If not, could the migration guide state the actual size limit (about 80K characters for an alternation inside a star), not just that "large inputs" can throw?

2. The initial plan isn't capped by the retention limit.

• The constructor starts at min(64, _maxFrames) frames (JintRegExpEngine.cs:98), and the fast paths at :205 and :311 keep that plan in t_scratch.
• Once a frame passes 4,096 ints (about 2,000 groups, or a deep task stack), that first plan is already over 1 MiB. Each thread then keeps it, up to the full 64 MiB at around 128K groups.
• The comment at :81 ("never above RetainedScratchInts") overstates it.
• A fix would be to start at the number of frames that fits RetainedScratchInts (at least one), or to send an oversized initial plan down the per-search path.

Gate. Since the head will change with the GregsEx sync, I'll run the x64 gate on that head, not this one. Today's quiet window is already booked for #4277 and #4265.

[sebastienros]

Thanks, Marko. Both points are addressed, and the GregsEx sync has landed, so 26f093590 is the head for your gate.

1. The ceiling. You were right about the size: I measured 82,239 characters for the tokenizer. sebastienros/gregsex#4 makes frames variable-length: a choice saves a fixed-width frame and trails only the task and register slots it changes. Measured on Jint's 64 MiB ceiling:

Pattern	Before	After
/"(?:[^"\\]|\\.)*"/	82,239	466,030
/(a|b)*c/	121,573	372,823
/(?:a|b)*c/	143,393	621,375

A literal containing escapes gets further (about 930K characters). main and V8 still match longer runs, so §4.161 now states these measured limits, notes that a single-character repeat ([ab]*, .*, [^"]*) has none, and suggests rewriting (?:a|b)* as [ab]*. GregsEx's own numbers for the change are in sebastienros/gregsex#4: a 1 MiB quoted string goes from 157 to 28 workspace ints per character, and from 48.9 to 27.0 ms. One shape got slower: groups inside an alternation inside a repeat, such as ((a)|b)+c, is 7–12% slower, so it may be worth a row in the gate.

2. The initial plan. Fixed in bf66ac477:

• A pattern starts at the frame count whose storage fits RetainedScratchInts. A pattern whose fixed part alone is over the cap starts at one frame and brings storage of its own to every search.
• The thread's arrays no longer double past the cap.
• The comment no longer overstates it.

After sebastienros/gregsex#4 a frame is a small fixed width and the registers are the fixed part, so the boundary is now a group count: about 65K groups, where the registers and their stamps pass 1 MiB. APatternWhoseStorageExceedsTheRetainedCapStartsAtOneFrame pins both sides: 3,000 groups start at 64 frames, 140,000 at one.

Also in this sync:

• Cold compile, against main (50 unique patterns per operation; alternating runs on a loaded machine, so treat these as approximate):

  Pattern	Before Cut the cost of compiling ECMAScript patterns gregsex#4	After
  \p{L} under u	+1,596%	+1%
  email pattern under i	+1,225%	+131%
  i classes	+461%	+101%
  plain email	+55%	+57%
  alternation	+48%	+59%
  literal	−10%	−26%

  What's left is per-pattern setup; it's listed in the design doc's follow-ups. RegExpColdCompileBenchmark has these shapes if you want them in the gate.

• Downlevel: System.Numerics.BitOperations, which the new GregsEx code uses, is polyfilled for net472 and netstandard2.0/2.1.

All suites, test262 (102,653 / 0 failed), the AOT example and the docs build pass on 26f093590.

[lahma]

x64 gate on 26f093590, stage 1 only: 3 rounds over 29 rows. The wins are large, but three SunSpider string rows and cold compile are slower in every round, so as measured I'd hold the merge. Under our rule these are stage-1 flags, not formal blocks: the stage-2 rounds didn't fit in today's window. At these sizes, though, I don't expect more rounds to change the reading.

Setup

• Code: base is main at 84fcbdc32. The candidate is that plus a --no-ff merge of 26f093590 (fb2ccb40e, clean).
• Local-only scaffolding on base, never committed, so both sides run the same harness:
  • RegExpColdCompileBenchmark.cs and RegExpShapeBenchmark.cs are copied from the PR, since both are new in it;
  • an ExecutePreparedOnMultipleEngines alias of main's ExecutePreparedWithRegexCompilationOnMultipleEngines.
• RegExpCustomEngineBenchmark: each side calls its own engine's direct API.
• Harness: measure-paired.ps1 stable mode, the default BDN job, affinity on CPUs 2–15 and blocking GC.
• Rounds: 3, alternating the order (b,c / c,b / b,c), each starting on a clean live CPU sample. Memory load was 43–46%.
• Reruns: desktop activity forced one whole-round rerun and ten row-level re-pairs; no flag below rests on a re-paired cell alone.
• Controls: StringSplit.SplitOnChar, StringReplace.ReplaceAllPattern, Dromaeo ObjectString[F,F] and ColdCompile control-concat. No control moved the same way in both orders, so the adjusted series stands, and every call below reads the same on raw.

Slower in all 3 rounds

row	base	candidate	raw Δ (95% CI)	adjusted Δ	allocation, cand/base
SunSpider string-tagcloud	30.37 ms	37.29 ms	+23.4% [+12.8, +24.7]	+23.7%	1.00
SunSpider string-unpack-code	35.93 ms	41.12 ms	+14.4% [+3.8, +21.6]	+14.4%	0.61×
SunSpider string-validate-input	19.52 ms	20.99 ms	+7.3% [+7.3, +7.7]	+8.0%	0.99
ColdCompile email-i	711.6 µs	980.0 µs	+37.7% [+29.5, +45.9]	+37.7%	5.28× (299 KB → 1.54 MB)
ColdCompile email	601.5 µs	821.8 µs	+35.6% [+33.3, +37.4]	+37.7%	8.58× (172 KB → 1.44 MB)
ColdCompile uprop-u	1.155 ms	1.519 ms	+30.1% [+28.6, +32.2]	+30.4%	1.64×
ColdCompile classes-i	1.572 ms	1.770 ms	+12.6% [+12.5, +13.7]	+12.9%	0.47×
Shape literal-test	2.367 µs	2.652 µs	+12.1% [+10.5, +12.4]	+12.1%	0.97
Shape icase-literal-test	2.458 µs	2.696 µs	+7.7% [+5.4, +10.5]	+8.0%	0.97
Shape literal-replace-g	2.596 µs	2.787 µs	+7.2% [+5.6, +9.5]	+7.5%	0.98
Dromaeo ObjectRegExp[F,T]	40.61 ms	41.95 ms	+1.5% [+1.3, +3.8]	+3.9%	1.00

• Flagged only on the adjusted series: SunSpider date-format-xparb (+1.2% raw, 2/3; adjusted +1.1%, 3/3) and Dromaeo ObjectRegExp[T,T] (+0.7% raw; adjusted +1.0%, 3/3).
• Leaning slower, 2/3: Handlebars ExecutePreparedOnMultipleEngines +6.1% [−1.8, +7.2] and Dromaeo ObjectRegExp[F,F] +3.9%.
• No change: ExecuteStringOnMultipleEngines +0.2% and ObjectRegExp[T,F] −1.4%.

Faster in all 3 rounds

row	base	candidate	raw Δ	allocation, cand/base
SunSpider regexp-dna	12.04 ms	5.43 ms	−54.9%	1.00
FreshEngine FreshEngineSource	61.47 µs	26.60 µs	−57.1%	0.24×
CustomEngine CaseInsensitiveScan	4.154 µs	2.503 µs	−39.8%	0 B
Match MatchGlobal	1.411 ms	933.1 µs	−33.9%	0.24×
Split Split	966.8 µs	784.7 µs	−19.0%	0.99
ExecLoop ExecWhileLoop	247.2 µs	218.9 µs	−10.2%	0.73×
CustomEngine AnchoredLiteral	30.0 ns	28.1 ns	−6.1%	0 B

Reading it

• The SunSpider rows are whole-script workloads, not micro rows, and each is slower in both orders.
  • string-tagcloud is mostly its parseJSON validation: three chained global replaces over a large JSON string, then a ^…$ test. The middle one is /"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(:?[eE][+\-]?\d+)?/g: an alternation with optional groups, replaced globally.
  • string-unpack-code is the packer's while(c--) p = p.replace(new RegExp('\\b' + e(c) + '\\b', 'g'), k[c]): one new RegExp per keyword, then a global replace. That makes it a run-time compile workload as much as a matching one.
  • string-validate-input evaluates a regex literal (/^[a-zA-Z0-9\-\._]+@…\.[a-zA-Z]{2,3}$/) inside a 4,000-iteration loop and calls .test once per iteration. So it pays for literal evaluation (JintLiteralExpression changed in this PR) as well as a short anchored match.
  • I haven't profiled any of them. If you want an A/B ETW profile of string-tagcloud from this machine, I can capture one.
• Cold compile: much better than your pre-sync numbers (email-i +38% against +1,225%; uprop-u +30% against +1,596%). But email and email-i still allocate 5–9× more per compile.
• The three Shape literal rows may not be real. They spend most of their time in vectorised SpanHelpers searches, where Support regular expressions with more than 255 captures #4240 showed a 64-byte loop-placement lottery: each process lands at one of two levels, and an unrelated diff shifts which. control-indexOf (no regex at all) showed exactly that: both sides were bimodal at about 1.95–2.01 or 2.74–2.75 µs per process, so it was dropped as a control. These three rows were uniform across 3 processes per side, which is too few to rule the lottery out, so treat them as suspects rather than findings. The SunSpider and cold-compile flags stand without them.
• ((a)|b)+c: no RegExpShapeBenchmark case has groups inside an alternation inside a repeat. The closest are template-replace-g (/(a)(b)?/g) and capture-match-g. A case for it would be worth adding.

The full table, the per-process levels and the re-pair log are kept locally. I'll re-run the gate, with stage 2, on whatever head you want measured next.

[sebastienros]

Thanks for the gate, Marko. The rows it flagged are addressed in GregsEx sebastienros/gregsex#5, now merged and vendored here at d949514fa. That PR adds:

• a FIRST-set start filter under a non-multiline ^;
• per-alternative ASCII start masks for alternations;
• \b plans for literals and for \b\w+\b;
• shared ASCII sets and pooled compile buffers;
• a position (Glushkov) automaton that runs in place of the VM where the next character decides.

The branch also merges main up to 4fd6bb98f; the head after d949514fa, 0c453aac4, only adds these numbers to the design doc.

Re-measured on x64

The setup is different from yours, so this is not a substitute for your gate:

• devbox1 (AMD EPYC 7763), measure-paired.ps1 with its defaults, 3 alternating rounds;
• base is main at c553a7870 plus the same local-only scaffolding you used (the two new benchmark files and the ExecutePreparedOnMultipleEngines alias);
• the candidate is d949514fa;
• the 47 rows are a superset of your 29.

Row	Your gate	Now	95% CI
SunSpider string-tagcloud	+23.4%	+0.8%	[−0.5, +2.2], no change
SunSpider string-unpack-code	+14.4%	−9.4%	[−13.3, −7.4]
SunSpider string-validate-input	+7.3%	−1.5%	[−5.8, −1.1]
SunSpider date-format-xparb	+1.2%	+0.3%	[−0.6, +1.2], no change
Dromaeo ObjectRegExp (four rows)	+0.7 … +1.5%	−1.0 … +1.6%	each includes zero
ColdCompile classes-i	+12.6%	−25.1%	[−26.3, −23.4]
ColdCompile uprop-u	+30.1%	+15.5%	[+14.2, +18.5]
ColdCompile email	+35.6%	+20.9%	[+18.0, +21.9]
ColdCompile email-i	+37.7%	+29.4%	[+29.0, +30.2]
Shape literal-test	+12.1%	+16.5%	[+14.0, +21.5]
Shape literal-replace-g	+7.2%	+14.0%	[+13.3, +14.5]
Shape icase-literal-test	+7.7%	+3.0%	[+0.8, +3.4]

Other rows in the same run: regexp-dna −55%, SplitUnicode −93%, MatchGlobal −32%, FreshEngineSource −57%, CaseInsensitiveScan −39%.

Still slower

• Cold compile of most shapes is +15 to +39%. That includes literal, alternation and tokenizer, which your run didn't cover. On the Mac these compiles still allocate 2 to 2.5× main; I didn't measure allocation on x64. What's left is per-pattern setup in the GregsEx compiler and accelerator. It's listed as a follow-up in docs/design/regexp-gregsex-migration.md §6.
• The literal scans are +14 to +17%: a 10-character literal that isn't in a 64 KiB subject. GregsEx already uses the fastest of IndexOf and SearchValues<string> for that subject. .NET Regex picks its anchor characters from a frequency table, which is the remaining gap; that's also in §6.
• greedy-dotstar-test is +7.9% and char-split +4.5% on x64, although the Mac reads both faster than main.
• The non-regex control. control-indexOf read +42.6% in this run, and +43.5% and −0.1% in two earlier runs of the same harness on this machine. I read that as a bimodal floor, not a regression, but it's one more reason to prefer your quiet-window numbers.

Backtracking ceiling (your earlier point 1)

/"(?:[^"\\]|\\.)*"/ and /(a|b)*c/ now run on the position matcher and need no frames: a 2,000,000-character string literal matches. The RangeError ceiling remains for what the matcher declines (lookarounds, backreferences, u/v, more than 256 positions). The migration guide now says so, and the tests and the AOT probe use a lookahead to keep exercising it.

When the head is stable for you, an x64 gate on it in your quiet window would settle whether the remaining rows block the merge.