Perf #856: throw (not a returning call) at loop-backedge cancel path — closes objects/strings/closures to Node parity

[nickna]

Summary

Closes most of the remaining compiled-vs-Node perf gap (epic #856) with a single low-risk codegen change to the loop-backedge cancellation check.

Every compiled loop polls a cooperative-cancellation flag at its backedge so the runner can unwind runaway loops (#74). The flag read is free, but the cold path was call $Runtime.CheckCancellation() — a helper that throws internally. From RyuJIT's flow-graph view that is a returning call, and on SysV x64 every XMM register is caller-saved, so a returning call inside a loop forces the loop-carried doubles (and the counter) to be stack-resident on every iteration — a load/store per use, roughly doubling a tight numeric loop.

Fix: the backedge now emits call $Runtime.BuildCancellationException(); throw. The new factory only constructs the OperationCanceledException; the throw opcode happens at the backedge. Because throw does not return, the loop vars are dead on the cancel path and stay in registers on the hot path. CheckCancellation() is retained for the non-hot-loop sites (event loop, deep-recursion guard).

This supersedes the inline-volatile form (#874), which removed the unconditional call overhead but left the returning call in the loop's flow graph, so the XMM spill remained. A throttle-every-N variant ties it for the same reason. The fix is structural: make the cancel path non-returning.

Why it works (controlled microbench, result*=i loop, Linux x64 / .NET 10)

variant	ns/iter
if(flag) call CheckCancellation() (old)	2.09
volatile flag read + branch only, no call	1.15
if(flag) throw Factory() (call factory, throw result)	1.15
no check at all	1.14

The entire penalty was the returning call, not the flag read.

Results — compiled vs Node, min times at largest input

Workload	before	after
objects	2.52× slower	1.00× — parity
strings	1.26× slower	0.91× — faster than Node
closures	1.13× slower	1.02× — parity
count-primes	1.45× slower	1.13×
factorial	2.27× slower	1.22×
fibonacci / array-methods	—	still 2–2.4× faster

5 of 7 workloads now meet or beat Node; the other two are within ~1.2× and now at the codegen floor (V8's multiply loop is ~0.2 ns/iter tighter; count-primes' residual is List<bool> index-write bounds checks). The change benefits all compiled loops, not just the benchmark suite.

Correctness

• IL verification passes on loop-heavy output (--compile … --verify).
• Execute_InfiniteLoop_CancellationUnwindsCooperatively (Test262 runner: compile-mode cooperative cancellation #74 guard) passes — runaway loops still unwind with the same OperationCanceledException.
• Full suite: 13998 passed. The handful of failures are pre-existing/flaky and unrelated: the non-Test262 ones pass in isolation (parallel-runner contention); the Test262 ones are stale-baseline drift (97–133 "new passes"), and the interpreter baseline shows the same drift despite sharing zero code with this IL-only change.

Files

• Compilation/EmittedRuntime.cs — BuildCancellationExceptionMethod field
• Compilation/RuntimeEmitter.RuntimeClass.cs — emit the factory method
• Compilation/StatementEmitterBase.cs — EmitCancellationCheck emits call … BuildCancellationException(); throw
• STATUS.md — §18 updated

Refs #856, #74. Supersedes the codegen approach in #874.