perf(vm): comparison fast path, integer %, non-allocating finally, dead-code cleanup

[mparrett]

Follow-up to the number-fast-path lane: the pieces of the dispatch-loop audit that lane didn't pick up. Five commits in distinct vm.go regions.

Stacks on the number-fast-paths PR. Until that merges, this PR's diff includes its parent commits (same pattern as #35 on #29). Rebase onto main after the parent lands — do not --delete the parent branch on merge.

What this does

• Numeric fast path for relational comparisons. <, >, <=, >= with two number operands — loop bounds, sort inner loops — take the same tag-direct path as arithmetic. No NaN special-casing: Go float comparisons already yield ECMAScript's result for NaN operands.
• Integer fast path for %. math.Mod is a software frexp/ldexp loop and was ~7.6% of the recursion benchmark's profile. Go's truncated int64 remainder carries the dividend's sign, matching JS; guarded for integral operands within ±2^53, nonzero divisor, and signed-zero results (deferred to math.Mod).
• Non-allocating finally check on returns. Every OpReturn / OpReturnUndefined called findAllExceptionHandlers, which heap-allocates a handler slice whenever the return PC sits inside a try region. Replaced with a single table-order scan returning the same handler; top-level-return test short-circuits on frameCount before the "<script>" string compare.
• Dead code out of the hot loop. Leftover debug blocks in OpGetGlobal / OpSetGlobal (type switch + Name loads + string compares into an empty if-body on every global load/store of a function). Plus an unreachable ip guard at the loop head and redundant IsNaN guards in the relational slow path.

Numbers

Local (M2): the % integer path alone is ~−15% on the recursion benchmark; together with the parent lane this is the shootout's full column (~−50% Fib / Matrix / Add / Arith vs upstream tip — noisy machine, alloc/GC signal was clean). Per-commit figures are in the commit messages. The perf label's same-runner A/B is authoritative.

Verification

• TestScripts green at every commit; tests/scripts/remainder_semantics.ts pins % sign combinations, signed zeros (via 1/x), zero divisor, Infinity operands, and the non-integral fall-through.
• Test262 language on the merged stack: 0 new failures, 0 new passes vs upstream tip.
• No semantics changes. Latent inconsistencies the audit surfaced (IsCallable vs IsFunction on async natives; OpIn accepted-type list) were deliberately preserved and will be filed separately.

Made with Cursor

[nooga]

Reviewed all four changes individually — the comparison fast path, integer `%` semantics, and the non-allocating `finally` refactor are each correct (verified against NaN/±0/sign edge cases and traced the finally-handler-selection logic against the old code path; `TestScripts` passes). Requesting changes for two reasons, not a rejection of the approach:

1. This is really 4+ unrelated changes bundled into one diff, beyond what the title says. Beside the stated comparison/%%/finally/dead-code items, it also touches `Value.IsObject()` (range-check rewrite), `Value.ToInteger()` (new fast path), and introduces a new process-global `arrayIndexAccessorSeen` latch that changes `OpSetIndex`'s inherited-setter walk — none of which are mentioned in the title/description. If something regresses later, this shape makes it hard to bisect which of the ~6 changes is at fault. Could you split this into smaller PRs (e.g. comparison+%%, finally, IsObject/ToInteger/array-setter-latch)?

2. Two concrete concerns worth addressing before merge:

• The dead-code cleanup removed the `ip >= len(code)` bounds guard, trading a graceful `runtimeError` for a Go panic/OOB if that invariant is ever violated by a future compiler bug. Given the project's "correctness first, no shortcuts" stance, I'd rather keep a cheap defensive check here than save a branch.
• `arrayIndexAccessorSeen` (object.go) is an unsynchronized global `bool`. It's fail-safe in the sense that a stale `false` just restores the slow path, so it's not a correctness bug — but it is a data race under `-race` or with concurrent VM instances, and worth at least a comment or atomic if that's a supported use case.

Also flagged as a minor, non-blocking irony: the "dead-code cleanup" itself reintroduces a few now-unreachable duplicate numeric-type guards inside `case OpAdd`/`OpSubtract`/`OpMultiply`/`OpDivide` that duplicate the combined fast path a few lines above — harmless, but worth a pass.

Happy to re-review quickly once split and the two concerns above are addressed — none of this is a fundamental problem with the approach.