Re-resolve slot locations when a shared handler tree changes function instance

[lahma]

#2613 shares one handler tree across the fresh function instances that a re-evaluated prepared script creates — but SlotLocationCache still assumed a node lives and dies with a single function instance. The cache stored the first instance's environment, and once that environment was no longer reachable from the current chain, TryResolve returned a permanent miss: it never fell through to re-resolution.

Net effect on main today: from the second re-evaluation of a prepared script onward (i.e. the second use of the #2613-cached tree), every slot-backed fast lane in that script is silently dead — unboxed loop counters, the comparison/equality lanes, fused modulo, sum-of-products — and every identifier read in a tight loop materializes a JsNumber through the generic path. The engine-reuse embedding scenario #2613 targeted is exactly the scenario that hits it.

How it surfaced: an A/B for a new lane showed its target row allocation-unchanged on both sides. A per-evaluation allocation probe with lane fire counters showed fires = 100k on evaluations 1–2, then 0 forever, with the allocation cliff at evaluation 3; decline-site counters pointed at the left slot resolve; the permanent-miss return in TryResolve was the mechanism.

The fix

When the hit-walk exhausts without reaching the cached environment (and without meeting a shadowing binding or a with-object — those still decline this read), fall through to ResolveAndPopulate and re-cache against the current chain — exactly what the existing cross-engine Prepared<Script> path already does on an engine-identity mismatch. Cost: one bounded, pure walk per instance switch; subsequent reads hit the re-populated cache. The fall-through is also cheaper than the old behavior on the miss path itself, which re-walked and declined on every read.

Benchmarks

LoopDispatchBenchmarks (one engine re-evaluating each prepared loop; every measured iteration past the first is a re-evaluation, so main's numbers are the degraded-lane floor):

Method	main	fix	Δ time	main alloc	fix alloc
EmptyLoop	4.114 ms	1.143 ms	−72.2%	2.74 MB	1.63 KB
VariableBoundLoop	4.809 ms	1.336 ms	−72.2%	2.74 MB	1.63 KB
CounterAdd	7.796 ms	2.058 ms	−73.6%	5.48 MB	1.63 KB
LocalCopy	7.315 ms	2.917 ms	−60.1%	2.74 MB	1.59 KB
StringAppend	6.984 ms	2.653 ms	−62.0%	2.94 MB	206.94 KB¹
ComparisonOnly	9.250 ms	5.066 ms	−45.2%	2.74 MB	1.59 KB
StrictEqualTest	8.392 ms	4.156 ms	−50.5%	2.74 MB	1.59 KB
LooseEqualTest	8.406 ms	4.076 ms	−51.5%	2.74 MB	1.59 KB
ModuloEqualTest	11.096 ms	5.651 ms	−49.1%	2.74 MB	1.59 KB

EmptyLoop returns to ~11 ns/iteration — the floor these lanes were built to deliver; on main every row was paying a JsNumber materialization per identifier read from the second evaluation on.

¹ StringAppend's remaining allocation is the rope builder for the 100k-char result string, not lane churn.

PreparedAnomalyBenchmarks guard (the #2613 gate):

Method	main	fix	Δ time	Allocated
SourcePerOp	13.93 ms	13.74 ms	−1.4%	45.25 KB (=)
PreparedShared	13.77 ms	14.08 ms	+2.3%²	23.69 KB (=)
PreparedPerOp	14.21 ms	13.96 ms	−1.8%	46.81 KB (=)
PreparedReusedEngine	15.64 ms	15.13 ms	−3.3%	9.99 KB (=)

² Within this row's run-to-run band; allocations byte-identical across all four rows.

Tests

New SlotLocationCacheTests: correctness pins for repeated prepared evaluations and for two function instances alternating over one shared tree, plus an allocation pin (net10.0) that fails on main (626 KB/evaluation for a 20k-iteration counter loop) and passes with the fix.

Full gate: Jint/Jint.csproj all TFMs, Jint.Tests (net10.0 + net472), Jint.Tests.PublicInterface (net10.0 + net472), full Test262 (single failure = Atomics/waitAsync/bigint/no-spurious-wakeup-no-operation.js, the documented wall-clock flake family — 8/8 green re-run in isolation, 88 tests per run).

🤖 Generated with Claude Code

https://claude.ai/code/session_01BY8HoKam5H8vTPn1bMY2Hv