GC: the two lazy intrinsic-tower builders need #7217's no-move window, and need a gate that can fail first

[proggeramlug]

Summary

#7217 established the invariant and fixed the one site that had a runtime witness:

A bootstrap that builds an IMMORTAL object graph through raw pointers held across its own allocations must run in a NO-MOVE WINDOW.

populate_global_this_builtins now runs in a GcSuppressScope, gated by a cargo-test-visible unit test that arms a collection, shows the bootstrap does not service it, and shows the same armed request IS serviced by ordinary allocation once the window closes.

Two sibling builders have the identical shape and are NOT covered, because I could not build a gate for them that can fail. Filing rather than shipping ungated, per CLAUDE.md's knob-kill policy ("shipping a GC-trigger change with no test that can fail without it is the thing [it] exists to stop", quoted verbatim at crates/perry-runtime/src/string/alloc.rs:49).

The two sites

builder	the raw locals	also reachable ahead of the bootstrap from
object/global_this/generator.rs::ensure_generator_intrinsics → build_generator_tower	*mut ObjectHeader / *mut ClosureHeader ctor+proto locals threaded across every allocating install in the tower	generator_function_proto_of, generator_function_prototype_of, generator_prototype_ptr — i.e. any program that reflects on a generator without touching globalThis
object/global_this/typed_array.rs::ensure_typed_array_intrinsic	ctor and proto, held across ~a dozen set_builtin_property_attrs / set_field installs	typedarray_props.rs:812

Both build an immortal graph (the towers hang off process-global intrinsic slots), so the same argument applies verbatim: a collection inside them frees nothing and can only move the holders out from under them.

When they are reached from populate_global_this_builtins they inherit its window and are safe today. The exposure is the lazy-ahead-of-bootstrap path only.

Why #7217 could not gate them, measured

populate_global_this_builtins is gateable behaviourally — arm a pending collection, run it, assert nothing collected — because it allocates ~1.15 MB and therefore crosses several arena block boundaries, and arena_alloc_gc calls gc_check_trigger() on each. A tower is three orders of magnitude smaller and fits inside one block's tail, so it can reach no trigger at all:

• a first version of the gate arming a collection around ensure_generator_intrinsics() passed with the GcSuppressScope deleted;
• a second version pre-filling to a block boundary, and re-execing the test binary so the child process is the first to touch a tower (the slots are process-global AtomicI64s, so libtest's name ordering meant array::tests's js_get_global_this() built them first and the test was measuring nothing) — also passed with the scope deleted;
• a third version recording gc_is_suppressed() from inside the builder under #[cfg(test)] reported suppressed even with the scope removed, which is unexplained and is itself a reason not to trust it as a gate. (Worth a look: something else may already be suppressing across part of the tower build — symbol/get.rs calls the manual gc_suppress()/gc_unsuppress() pair at three sites, and well_known_symbol is on this path.)

What would close this

Either of:

1. A workload witness. A gap test that reflects on a generator (or touches a typed array) under enough allocation pressure to put a collection inside the tower build, run on the allocation-point arm (PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off) with PERRY_GC_PROTECT_FROMSPACE=1. If the quarantine faults inside build_generator_tower, the window is justified and the witness is its gate.
2. A trigger the tower's size can reach. GcTriggerThresholdTestGuard::make_malloc_sweep_due() arms the malloc-count trigger, which gc_check_trigger sees on every gc_malloc rather than once per arena block. If the tower's installs go through gc_malloc at all, that gives a lever a few-hundred-object build can actually trip.

Resolve the third bullet's anomaly first — if something already suppresses across these builds, the windows may be redundant rather than missing, and that is a better answer than adding them.

Refs #7217, #7196.

[proggeramlug]

Confirmed still open on main = d4ac65f21. Re-verified in the sweep #7262.

Neither builder has a no-move window:

• crates/perry-runtime/src/object/global_this/generator.rs — no GcSuppressScope; build_generator_tower at :490, ensure_generator_intrinsics at :609.
• crates/perry-runtime/src/object/global_this/typed_array.rs — no GcSuppressScope; ensure_typed_array_intrinsic at :418.

This matches #7249's own "Known issues" note, which recorded that windows for both were written and then deliberately dropped rather than shipped ungated, per the knob-kill policy. Nothing since has added them.

The sibling site is now verified fixed: populate_global_this_builtins's window is real and load-bearing — #6991 and #6992 both closed on it in this sweep, each green at ~3.4× the movement level their crashes were originally observed at. So the invariant this issue is built on ("a bootstrap that builds an IMMORTAL object graph through raw pointers held across its own allocations must run in a NO-MOVE WINDOW") now has two independent confirmations behind it, which strengthens the case for the two remaining towers.

The open question is still the gate, not the fix, and the issue's third bullet — gc_is_suppressed() reporting suppressed from inside the builder even with the scope removed — remains the right thing to resolve first. symbol/get.rs's manual gc_suppress()/gc_unsuppress() pair at three sites is still present in the tree and well_known_symbol is still on this path, so that hypothesis is intact and untested.

[proggeramlug]

Heads-up before anyone invests here — this issue is in a class that a planned architectural change would make unrepresentable, and I don't want someone building new machinery that gets deleted.

See docs/src/internals/rfc-rooting-by-construction.md ("Where this sits in the one GC correctness plan", landed in #7292). Short version: this is layer 2 — a GC-managed pointer live in emitted machine code across a point where the collector can run. Statepoints/stack maps (#7108, #7174, enabled by #7241) would have LLVM track that liveness precisely, so the whole shape stops being expressible.

This is not "don't fix it". The architectural change is weeks away, the bug is real now, and correctness comes first — please do fix it.

It is "fix the instance, don't build new mechanism." Specifically:

• A targeted root/RuntimeHandleScope/GcSuppressScope at the site: good, lands now, survives.
• A new predicate, a new shadow-slot allocation scheme, or a new hand-maintained table deciding what to root: please raise it first. codegen: ClassExprFresh leaves the class object unrooted across its own js_object_set_field_by_name stores #7211 is the cautionary case — a four-clause predicate written by someone actively thinking about rooting, still wrong, because it asked about the user's expressions rather than the lowering's own emitted calls. Statepoints delete that entire category of judgement call.

Also worth knowing when you verify: PERRY_GC_MOVING_LOOP_POLLS=1 set at run time against a default-compiled binary is clean 10/10 and proves nothing — the poll codegen isn't in the binary. Compile-time and run-time env must both be set (#7280). And a green run that performed zero copying minors proves nothing either (#7255) — assert copied_objects > 0.