gc: a relocating minor with PRECISE roots breaks 14 of 20 representation-corpus files (5 crashes, 9 mismatches) — the conservative stack scan is load-bearing for correctness

[proggeramlug]

Found by #6977, which made the evacuating minor reachable for the first time. #6950's premise held: nothing had ever moved, so nothing had ever tested this.

Result

scripts/gc_repsel_matrix.sh --arms all --pressure 8, release build, macOS arm64, pinned Node 26.5.0, with the evacuating base from #6977:

arm liveness across the corpus:
  evac_minor          requires=move     collected 19/20   moved-objects 19/20

Evacuation is now genuinely live on 19 of 20 corpus files — and 14 of 20 break.

The discriminator is precise roots, not relocation

Both columns collect and both relocate. The only difference is whether the conservative native-stack scan is running.

corpus test	PERRY_GC_INCREMENTAL=0 (conservative scan ON)	+ PERRY_CONSERVATIVE_STACK_SCAN=off (precise roots)
repsel_canonical_i32	OK (1 122 copied)	SIGABRT (4 579 copied)
int_valued_ta_locals	OK (12)	OK (12)
specabi_polymorphic_coexist	OK (1 099)	mismatch (9 647)
specabi_reassign	OK (1 101)	mismatch (9 671)
specabi_recursion_escape	OK (4)	OK (4)
specabi_view_detach	OK (6)	OK (6)
ta_param_numeric_read	OK (15)	SIGSEGV (5 948)
typedarray_param_read	OK (15)	SIGABRT (5 965)
repsel_canonical_str_locals	OK (0)	OK (63)
repsel_ptr_shape_locals	OK (6)	SIGABRT (4 640)
repsel_ptr_shape_barriers	OK (5 923)	SIGSEGV (4 616)
repsel_p4a_holes_axis	OK (5 888)	OK (4 602)
repsel_p4a_inline_tiers	OK (5 631)	mismatch (10 621)
repsel_p4a_logical_numeric	OK (5 633)	mismatch (10 636)
repsel_p4a3_numarray_barriers	OK (18)	mismatch (15 297)
repsel_p4a3_numarray_growth	OK (0)	OK (0)
repsel_p4a3_ptr_numarray	OK (5 637)	mismatch (10 639)
repsel_p4b_field_store_elision	OK (0)	mismatch (9 698)
repsel_gc_stress	SIGSEGV — separate defect, see below	mismatch (1 573 353)
repsel_proven_this_frozen	OK (5 935)	SIGSEGV (4 614)

(N copied) is [gc-copy-minor] ran copied_objects=N summed over the run — the collector's own evidence that survivors were relocated.

Read that table carefully: relocation with a conservative scan is fine. 19/20 pass while copying thousands of objects. What breaks is relocation with precise roots — i.e. exactly the values that only the conservative scan was keeping alive or keeping correct, which is the class #6951/#6972 opened and #6968/#6969/#6970/#6971 enumerate. This is the same conclusion #6972's commit message reached ("the scan was doing load-bearing correctness work, not acting as a safety net"), now measured across the corpus instead of on one shape.

Minimal reproducer

test-files/test_gap_specabi_reassign.ts, 20 lines, no loop:

function first(a: any) { return a[0]; }

let P = new Int32Array(4);
P[0] = 42;
console.log("before:", first(P));

P = new Int32Array([7, 8]);
console.log("after:", first(P));

$ PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 ./test_gap_specabi_reassign
before: 42
after: 7          <- correct, 1 101 objects copied

$ PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off \
      PERRY_GC_TRACE=1 PERRY_GC_DIAG=1 ./test_gap_specabi_reassign
before: 42
after: undefined  <- 9 671 objects copied
third: 99 1

before: and third: are correct; only the middle call is wrong, and only in the run where a collection lands inside it. The value reaching first is a typed array passed under the specialized ABI — a raw unboxed pointer, which is neither a shadow-stack root nor a slot an evacuating cycle rewrites. The pre-collection register is stale afterwards, and a[0] reads through it.

Note this is the SAME defect shape as #6951 (an SSA register holding the only reference across a collection point), one layer further in: #6972 rooted the argument accumulator; this is the argument value itself when the specialized ABI passes it raw. #6969 (ctor args), #6970 (native-method args) and #6971 (string-method receiver + args) are neighbouring cases; this one is an ordinary user-function call.

Why this matters more than the count

PERRY_CONSERVATIVE_STACK_SCAN resolves Auto -> SkipDisabled in shipped builds. The only reason precise roots are not already the shipped behaviour on the automatic paths is that gc_check_trigger forces ManualGcScanGuard::force_full_scan() on both arms. That forced scan is currently load-bearing for correctness on 14 of 20 representation-corpus files. Any change that removes it — which is the direction the moving-GC work is going — turns this table into production behaviour.

Reproducing

cargo build --release -p perry -p perry-runtime -p perry-stdlib \
                      -p perry-runtime-static -p perry-stdlib-static
scripts/gc_repsel_matrix.sh --arms evac_minor --pressure 8 --no-build

(needs #6977 for the evac_minor arm; before it, every one of these cells reported UNVERIFIED because nothing moved.)

Related: #6950, #6977, #6951, #6968, #6969, #6970, #6971, #6942, #6946.

[proggeramlug]

Cross-check from #6983 (#6969/#6970/#6971), since these sit adjacent.

Orthogonal site, same class — #6983 does not close this. #6981's repro goes
through the specialized-ABI call path for an ordinary user function; #6983
touches only lower_new, lower_string_method and the Map/Set collection-method
lowering. None of them is involved in first(P).

It is the same class, though, and the connection was load-bearing rather than
decorative — reviewing #6983 against this issue's mechanism exposed a real hole
in it. A temp root buys two separate things:

1. liveness — the object is marked instead of swept;
2. a location the collector rewrites — so the value survives relocation.

#6983 had a gate (operand_needs_root) that suppressed rooting for operands
which are already registered roots — a shadow-slotted local, a module global, a
string literal. That is sound for (1) and unsound for (2): evacuation rewrites
the storage, and the register loaded beforehand still holds the pre-move
address. Which is exactly what this issue reports one layer in. It is now fixed
there by re-loading the operand at the re-read point instead of reusing the
register — correct under relocation and a plain load, not a runtime call.

Worth noting for whoever takes this: the fix shape for a raw unboxed pointer
under the specialized ABI cannot be "re-load", since there is no rooted storage
to re-load from — it has to be a real temp root, or the ABI has to spill to a
shadow slot.

Also a data point on severity, measured on this branch rebased onto #6977
(PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off PERRY_GC_HEAP_LIMIT=8,
786 490 objects genuinely copied): #6969/#6970/#6971's own reproducers SIGSEGV on
main under that arm, and two of the three still do with their named bug fixed.
Those programs do sink.push({...}), a template concat and an array literal per
iteration, so they are hitting this class at other sites — consistent with the
14/20 in the table above, and a reminder that the corpus files are not
single-shape tests.

[proggeramlug]

The stated soundness argument, and why it does not hold

Analysis from reading the source on e70ffe29d — not re-measured; the table above is the measurement, this is an attempt to name the mechanism so a fix can be scoped.

The TaPtr entry binding is crates/perry-codegen/src/codegen/function.rs:484:

Some(crate::collectors::SpecParamRep::TaPtr { .. }) => {
    let boxed = crate::expr::nanbox_pointer_inline(blk, &arg_name);
    let slot = blk.alloca(DOUBLE);
    blk.store(DOUBLE, &boxed, &slot);
    // No callee-side shadow binding: every route into this
    // entry is a Tier-A call whose argument is a proven
    // never-reassigned rooted binding (module-global root or
    // caller-frame slot) that stays live for the whole call,
    // and typed-array storage is non-movable — the callee
    // root would be redundant TLS traffic on the hot path.
    map.insert(p.id, slot);
    continue;
}

That comment carries two load-bearing claims, and the failure needs only one of them to be false.

Claim 1 — "typed-array storage is non-movable"

True, and irrelevant to what is actually passed. %arg is the header pointer — the code NaN-boxes it (nanbox_pointer_inline), i.e. it is a POINTER_TAG reference to a GC-allocated view object. Storage non-movability says nothing about the header that holds the data pointer and length.

CLAUDE.md already flags this exact trap for this exact representation:

spec-ABI raw params (TaPtr) | #6905 | typed-array storage is non-movable ⇒ no callee-side shadow bind (objects are movable — that shortcut must NOT generalize)

A typed-array view is an object. The shortcut generalized anyway — the module doc at codegen/spec_abi.rs:11-14 repeats it ("sound because typed-array storage never moves").

The callee's alloca is deliberately not js_shadow_slot_bind-ed, so an evacuating cycle rewrites the caller's rooted slot and leaves both the callee's %arg register and its boxed copy pointing at the pre-move header. That is precisely "neither a shadow-stack root nor a slot an evacuating cycle rewrites" from the report above. Note the entry hoists data pointer + length from that header, so a header that moved before or during entry yields a garbage hoist even though the storage itself never moved — which is consistent with a[0] reading undefined rather than crashing.

Claim 2 — "a proven never-reassigned rooted binding"

The minimal reproducer is test_gap_specabi_reassign.ts and its body is:

P = new Int32Array([7, 8]);

P is reassigned. Either the never-reassigned proof does not cover module-globals across reassignment, or it is not consulted on this route. Worth determining which, because it decides whether the proof needs strengthening or the shortcut needs removing outright.

Fix shapes, cheapest first

1. Shadow-bind the TaPtr param slot (emit js_shadow_slot_bind for the alloca, as the _ => {} fallthrough path already does at function.rs:500-506). The existing comment rejects this as "redundant TLS traffic on the hot path" — that is a performance justification resting on a soundness claim that is false under evacuation. Since perf(codegen): representation-selection Phase 2 — specialized calling convention (bounded monomorphization) #6905 shipped, --arms all reports whether the cost is real; perf(codegen): representation-selection Phase 1 — canonical unboxed i32 locals #6903's canonical-i32 work is the precedent for measuring it rather than assuming.
2. Re-derive after safepoints — keep the raw parameter, re-read the header through a rooted location at each safepoint, mirroring the Ptr<Shape> / Ptr<NumArray> discipline (raw pointer is region-local SSA only, re-derived after every safepoint) that perf(codegen): representation-selection Phase 3b — shape-proven object locals (Ptr<Shape>, delete the guard diamond) #6911/perf(codegen+runtime): representation-selection Phase 4a — fast plain-array numeric elements (inline tiers, holes axis, self-healing bindings) #6915 already established. Consistent with the rest of the representation family.
3. Pin typed-array view headers. Not recommended — it makes a GC policy change to preserve a codegen shortcut, and pinning is what fix(gc): make argument temporaries precise roots (#6951) #6972 deliberately avoided so evacuation could expose exactly this class.

(1) restores the invariant the other five representations already honour; (2) is faster on the hot path but is a larger change and needs the safepoint set enumerated. Whichever is chosen, the two comments above — function.rs:488-493 and spec_abi.rs:11-14 — must be corrected, since they are what made this look settled. Cf. #6987, where two other GC doc comments asserted the opposite of the code.

Acceptance

The fix should be verified on the evacuating, precise-roots arm, not the default one:

PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off

with [gc-copy-minor] copied_objects=N confirming relocation actually happened — a green run where nothing moved proves nothing, which is the failure mode #6942/#6946/#6950 documented and #6977 finally removed.