Capture-by-reference for class-member var captures costs +22-24% on the shapes it fixes (#10485 follow-up) #10616

Follow-up to #10485/#10489, fixed in PR #10615. Filing for tracking only — the fix is correct and should ship.

Measurement (from PR #10615, perf stat -e instructions, 3 runs each)

The controls matter: the cost is confined to the shape the fix repairs, not spread across closures generally.

Why there is no valid "before" number

The baseline was faster because it silently skipped the write-back this fix performs — a var captured by a
class member fell back to a stale value-snapshot, so constructor and static-method writes were dropped entirely.
Measuring "the regression" against code that didn't do the work is measuring nothing.

This is the fourth instance of one pattern

Four correctness fixes in the package-audit campaign have landed with an instruction cost whose baseline was
invalid for the same reason — the old path was cheap because it was wrong:

• Guarded builtin-named method dispatch is 3-4x Node on dayjs/decimal-shaped receivers (#10476 follow-up) #10594 — guarded builtin-named dispatch, 3–4x Node (baseline crashed or returned the wrong number)
• instanceof per-value-kind receiver resolution costs +32.6% on constructor-shaped allocation (#10478/#10479 follow-up) #10602 — instanceof per-value-kind receiver resolution, +32.6% (baseline segfaulted)
• PR fix(hir,codegen,runtime): make arguments in class constructors reflect the call site #10612 — arguments in value-constructed classes, ~+20% (baseline never materialized arguments)
• this one, +22–24% (baseline dropped the write)

Worth asking whether they share a cause: each replaces a wrong-but-cheap fast path with a correct path that
re-derives or re-resolves something per operation. If so, the same class of fix — resolve once and cache at the
call site, rather than per operation — may address several at once. #10414 is the precedent: Array.prototype.push
re-derived its receiver 6x per call, and fixing that was worth −74.6%.