gc-ratchet is unconditionally red on main: the pinned baseline predates #7161's evacuating-minor flip

[proggeramlug]

Summary

gc-ratchet's pinned baseline (benchmarks/gc_ratchet/baseline/gc-ratchet-v1.json, commit 88dcee83b, captured 2026-07-30) was taken while the evacuating minor was the default. #7161 then flipped it off pending #7154. The baseline therefore describes a collector the shipped configuration no longer runs, and the gate is red on main for every commit since.

Measured locally on the pinned host class (darwin-arm64, Apple M1, 8 core, idle, --repeats 7), during PR #7207:

arm	check --profile shared_ci	gated REGRESSION rows
origin/main 3a983ca6a	exit 1	69
#7207	exit 1	69 (identical row set)

Every one of the 69 is minor_cycles / step_cycles / copied_objects / copied_bytes / promoted_objects / promoted_bytes / freed_bytes reading … → 0, plus the heap_used_bytes / heap_total_bytes growth that follows from nothing being collected. --profile pinned_host adds 17 rss_bytes/peak_rss_bytes rows for the same reason. wall_ms is inside band on every probe.

Why this compounds #7205

#7205 established that gc-ratchet's main runs are cancelled while queued, so the gate has executed zero times in three merges. Even once that is fixed, it will come back red on the first run — and a gate that is unconditionally red is exactly as informative as one that never runs. Both halves have to land for it to gate anything.

The two options, and why one of them is wrong

• Re-pin the baseline now on the shipped (non-moving) configuration. This makes the gate green — and makes copied_objects, promoted_objects and freed_bytes permanently zero-baselined, i.e. dark for exactly the collector behaviour they exist to gate. Any future evacuation regression would then have to move a counter that is pinned at 0 in both directions. This is the shape CLAUDE.md calls "the gate runs but its subject never did".
• Carry it as a known-red until fix(gc): disable evacuating minor by default pending #7154 (use-after-free on dynamically-added fields) #7161 is reverted, and re-pin as part of that revert, on the configuration the revert restores. The evacuation counters then have a live, non-zero baseline again.

The second is correct, but it needs to be a decision on the record rather than an accident, because until it is, every PR author who runs the ratchet rediscovers this and has to prove their own change is not the cause (PR #7207 did exactly that, by measuring both arms).

Ask

Either pin this to the #7161 revert explicitly (a line in the workflow and in the baseline artifact saying "known-red until the evacuating minor is default again; do not re-pin before then"), or re-pin with an explicit note that the evacuation counters are inert until the revert. Silence is the one option that keeps costing people time.

Refs #7205, #7161, #7154, #7207, #7019.

[proggeramlug]

Measured proof that the baseline, not the collector, is the whole delta — from #7196's gate run on the pinned host (idle mini, darwin-arm64):

gc-ratchet exits 1 on both profiles with 86 gated regressions, all evacuation counters going to zero. Re-measuring the same binary with PERRY_GC_MOVING_LOOP_POLLS=1 reproduces the pinned baseline exactly on every probe — minor_cycles 14/10/22/104/26/64/80/84, copied_objects within ~1%.

The baseline was pinned at 88dcee83b (2026-07-30), before #7161 flipped the evacuating minor default-OFF. So the ratchet currently reports 86 regressions on any correct build, i.e. it cannot gate anything.

Two options, and the choice interacts with #7161's revert timeline:

1. Re-pin now at a current commit under the shipped default — restores gating immediately, but the evacuation counters become all-zero baselines that assert nothing about evacuation until the revert.
2. Wait for the fix(gc): disable evacuating minor by default pending #7154 (use-after-free on dynamically-added fields) #7161 revert and re-pin once — keeps the counters meaningful, but leaves the ratchet non-functional meanwhile (and per CI: gc-ratchet's main runs are cancelled while queued, so the gate has executed zero times in three merges #7205 it has been executing zero times on main anyway).

Recommend (1) plus a note in the baseline file recording that the evacuation columns are inert until the revert, so nobody reads a green as evacuation coverage.