Default GC: array from a direct function call, stored in a variable, is lost when its backing store grows past 32MiB; object arrays get corrupted length

[dlee]

What happened

An array built with push inside a function, returned from a direct call,
and stored into any variable (local or global) is lost once its backing store
exceeds 32MiB. Deterministic, default GC, perry run and compiled binaries
alike. Numeric arrays come back with length === 0 (OOB reads give NaN);
object-element arrays get a garbage length (e.g. 2775006632) — memory
corruption. Exact boundary: build(4194304) (2^22 f64 slots = 32MiB) is
correct, build(4194305) is empty; object arrays fail from 2^21 (same 32MiB).

Same size works via: direct use (build(n).length), indirect call
(var f = build; f(n)), IIFE, or inline module-scope build.

What you expected

b.length === 4194305 (Node agrees). Perry prints 0.

Minimal reproduction

function build(n) {
  var a = [];
  for (var i = 0; i < n; i++) a.push(i);
  return a;
}
var b = build(4194305); // 2^22 elements is fine; 2^22+1 loses everything
console.log(b.length, b[0]);

Command you ran:

perry run arrayloss.js

Environment

• Perry version: 0.5.1220
• Host OS: macOS 27.0 (arm64)
• Target: native
• Installed via: npm

Diagnostic output

$ perry run arrayloss.js
0 NaN
$ node arrayloss.js
4194305 0

PERRY_GC_DIAG=1 on the compiled binary: one full collection frees ~32MiB —
the array's live buffer is swept (evacuation never runs, moved_objects: 0):

[gc] blocks: general=1 (1 live), longlived=10 (1 live), freed_bytes=33538224 retained_forwarded_stub_bytes=16368 retained_forwarded_stub_objects=7

Looks like the grow past 32MiB triggers a full GC that doesn't see the
direct-call return value as a root.

Anything else

Reproduces with PERRY_NO_CACHE=1; no PERRY_GEN_GC* / stack-scan setting
changes the outcome. Distinct from #5467/#5459/#6219, which need
PERRY_GC_FORCE_EVACUATE=1 or explicit gc() — this is default settings,
and no evacuation is involved. Found while benchmarking for #6223.

[proggeramlug]

Triage (confirmed, root-caused to class):

• Reproduced exactly (0 NaN at 4194305). Also reproduces identically under PERRY_GC_INCREMENTAL=1 — so this is not collection-machinery (either mode); it's upstream, in rooting.
• Your PERRY_GC_DIAG line is the tell: freed_bytes≈33.5MB is the array's current live backing store. For that buffer to be swept, the array→elements edge was never followed, i.e. the array header itself was never marked — the local a inside the direct-call function is invisible to the root scan at the alloc-point trigger the 32MiB grow fires. After the sweep, the grow completes against freed memory: numeric arrays read back length 0, object arrays read a garbage length (the corruption you saw).
• The direct-call vs indirect/IIFE asymmetry matches a known class from the 2026-07-09 GC audit (Method/closure bodies get no shadow-stack GC frames #6081-family): codegen keeps the value in a register/frameless window without a shadow-stack spill, and the conservative stack scan misses it there (NaN-boxed pointers on arm64 can sit in FP registers, which stack-word scanning never sees).
• Why 32MiB exactly: smaller builds never allocate past the GC trigger while inside the vulnerable window; the 2^22→2^23 grow is the first allocation big enough to fire a collection mid-push with the array live only in that unrooted local.

Fix therefore lands in codegen shadow-stack spilling for direct-call locals holding heap values across allocating calls (or conservative register capture), not in the collector. It affects the default and incremental collectors equally and is queued in the GC-soundness campaign (#6180 umbrella) as its own item. Workaround until then: any of the shapes you found (indirect call/IIFE), or PERRY_GC_HEAP_LIMIT large enough to defer collection past the build.

[proggeramlug]

Root-caused and fixed — and the triage above needed one correction, found by tracing the actual HIR/LLVM: the direct-vs-indirect asymmetry is the interprocedural deforestation pass (direct non-consumer calls get rewritten to pass a caller-allocated array by value with NO return; closures/IIFEs bail the pass), and the loss mechanism is a GC tracer gap, not rooting: array growth installs a permanent forwarding stub at the old address so stale pointers keep resolving for READS, but the shared mark tracer treated FORWARDED headers as zero-children — liveness never hopped to the live post-growth array, so the first collection after the 32 MiB grow swept it. Shadow frames and the conservative scan were empirically ruled out (toggling them changes nothing).

Fix: the worklist tracer now follows the forwarding edge and marks the target (one shared choke point, all GC modes). Your exact repro now prints 4194305 0, Node-equal, under both the incremental default and PERRY_GC_INCREMENTAL=0. Regression test added (stale-stub-as-only-root survives a full cycle). Ships with the #6180 default-on PR.