Allocation-free for-in key enumeration

[lahma]

for-in previously allocated per loop: an unconditional HashSet visited-set (plus its entry/bucket arrays), nested per-prototype-level C# iterator state machines (ObjectInstance.GetKeys recursion — one state machine and set per level), and an EnumerableIterator wrapper; and per step: an IteratorResult object. The allocation census put this machinery at 40-55% of enumeration-heavy workloads.

A dedicated IteratorInstance.ForInIterator now walks own string keys level by level, probing presence/enumerability per key at step time through the allocation-free ProbeOwnProperty (#2585) — deleted-before-visit keys stay skipped, per-level key snapshots keep proxy ownKeys/getOwnPropertyDescriptor trap ordering. The shadow set for deeper levels materializes only when a deeper level actually produces a present and enumerable key: exhausted level snapshots are retained as list references and re-probed once to build the set on demand. Prototype members are overwhelmingly non-enumerable, so common enumerations (plain objects, arrays, handlebars-style extend) allocate no set at all.

The step protocol gains IteratorInstance.TryStepValue, which skips the per-step IteratorResult for iterators that can and is byte-for-byte the old TryIteratorStep + Get(value) sequence for every other iterator; the for-in/for-of sync loop consumes it. ObjectInstance.GetKeys (sole consumer: the for-in head) is removed.

Measurements

Fresh-engine probes (A/B/A/B, alternating binaries):

workload	main	PR	delta
for-in over 1000-element arrays (fresh array per round)	78.2 MB/iter, 68.5 ms	28.5 MB/iter, 58.9 ms	-64% alloc, -14% time
handlebars-style extend() (for-in + hasOwnProperty per key)	107.2 MB/iter, 105.9 ms	58.2 MB/iter, 89.0 ms	-46% alloc, -16% time

IteratorResult, HashSet entries/buckets and the <GetKeys> state machines disappear from the allocation profiles; what remains is member-read Reference traffic and the key snapshots themselves.

BenchmarkDotNet default jobs (A/B vs main from separate worktrees): PreparedScriptBenchmark prepared modes -1.3/-1.8% time, -2.2% alloc; ObjectEnumerationBenchmark and DromaeoBenchmark.ObjectArray flat (they use Object.keys, not for-in); PreparedScript source mode within its observed run-to-run band with allocations down.

Verification

• Jint.Tests green (net10.0 + net472), Jint.Tests.PublicInterface green
• Full test262: 99,260 passed, 0 failed — for-in order, shadowing by non-enumerable shallower keys, delete-during-enumeration, proxy trap order all covered
• Live-engine checks: proto-chain order, non-enumerable shadowing across levels, delete-during-enumeration

🤖 Generated with Claude Code