GC: module-global array populated in a closure loses all elements under PERRY_GC_FORCE_EVACUATE (no weak refs)

[proggeramlug]

Summary

Under the full-evacuation stress mode PERRY_GC_FORCE_EVACUATE=1, a strong, module-level array that is populated from inside a function (closure/IIFE) loses all its elements after allocation churn + gc(). No weak references are involved. Distinct from #5459 (which was a closure array-push write-back codegen bug, fixed by #5461 and correct under default GC) — this reproduces only under forced evacuation.

Repro

declare function gc(): void;
function churn(n: number): void {
  let j: any[] = [];
  for (let i = 0; i < n; i++) { j.push({ i, p: "z".repeat(40) + i }); if (j.length > 128) j = []; }
}
const strong: any[] = [];
(function setup() { for (let n = 0; n < 40; n++) strong.push({ id: n }); })();  // populate from a fn
for (let c = 0; c < 12; c++) { churn(80000); gc(); }
let alive = 0;
for (let n = 0; n < 40; n++) if (strong[n] && strong[n].id === n) alive++;
console.log("strong-array alive:", alive, "/ 40");

• Default GC: 40 / 40 ✓
• PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1: 0 / 40 (5/5 runs). VERIFY does not panic, so no dangling-forwarded-ref is detected — the elements are simply collected despite the live strong reference from the module-global array. Downstream, accessing the freed elements can SIGSEGV (heap-layout dependent).

Notes

• Module-scope population of the same array is unaffected; the IIFE is the trigger (same shape as GC use-after-free: objects pushed to a module-level array from inside a function are freed under allocation churn + gc() #5459, but here under forced evacuation).
• Affects any weak collection whose targets are held in such an array (surfaced while landing WeakMap/WeakSet weakness, globals: make WeakRef and FinalizationRegistry actually weak #2656): the held objects get freed under FORCE, then weak-collection accesses fault.
• Suspected: evacuation of an object reachable from a module-global array doesn't repair the array slot to the forwarded address (or the array's element edges aren't re-marked) under the force-evacuate path. Needs GC copy/fixup investigation (gc/copying.rs, root/remembered handling for module-global array roots).

Impact

PERRY_GC_FORCE_EVACUATE is a debug/bisection mode (gc-stress CI, tag-gated), so no production impact — but it currently makes that stress mode unsound for an ordinary code shape, which limits its usefulness as a correctness gate.

[proggeramlug]

Localized

The array header survives under FORCE (strong.length === 40); it's the element objects that are freed — strong[n] holds stale pointers to evacuated-then-collected {id:n} objects.

Narrowed to the exact shape (all under PERRY_GC_FORCE_EVACUATE=1, on the #5461 base):

Shape	Result
for (n) strong.push(...) at module scope	40/40 ✓
array built+populated in a fn and returned (const strong = build())	40/40 ✓
module-global array pushed from inside a closure/IIFE	header intact, 0/40 elements ✗

So it's specifically a module-global array referenced only via the precise global root and populated through the closure push path (the PATH-2 module-global store-back in expr/array_push.rs). The module-scope / local-returned variants survive because the array stays pinned via a conservative stack root (its local alloca), so it's never evacuated; the module-global-only array is evacuated under FORCE and its element edges aren't kept/repaired.

Suspected: when such an array is evacuated, its backing's element pointers aren't repaired to the forwarded element addresses (or the array→element edges aren't re-marked) — so the elements are swept. Needs GC copy/fixup work for precise-root arrays under the evacuation path (gc/copying.rs). No production impact (FORCE is a debug/bisection mode), but it makes the gc-stress gate unsound for this ordinary shape.

[proggeramlug]

Ruled out a missing write barrier: js_array_push_f64 already records each pushed slot via note_array_slot (push_pop.rs:203-205, the grow path too), so the array→element edge is tracked. The element loss is therefore in the evacuation copy/fixup — when the array itself is evacuated (precise-root-only, so not conservatively pinned), its backing's element pointers aren't repaired/kept. Same class as the #5468 weak-slot-under-evacuation limitation: the force-evacuate path doesn't reliably repair pointer slots of evacuated objects. Core gc/copying.rs work; needs GC-evacuation context.

[proggeramlug]

Cannot reproduce on current main + the GC campaign branches: module-global array populated inside a closure (60k pushes with churn) is byte-correct under PERRY_GC_FORCE_EVACUATE=1 (synchronous moving), under the incremental default, and under PERRY_GC_VERIFY_EVACUATION=1 which panics on any un-rewritten slot. Module-global rewrite coverage was reworked across #6191 (rooted rebuilt closures / raw-ptr windows) and the uniform NaN-boxed global roots (marked AND rewritten on evacuation). Reopen with a failing repro if it resurfaces.