gc: incremental mode starts a budgeted cycle and never completes it — a small compiled program still performs ZERO automatic collections (#6950 residue)

Split out of #6950. #6977 fixed the arena-triggered half of this; the malloc-triggered half survives, and it is why a small compiled program still performs ZERO automatic collections in the shipped (incremental) configuration.

Symptom

A compiled program in the default configuration reaches a due GC trigger, starts a budgeted cycle, and never finishes it. Measured on origin/main + #6977, release build, macOS arm64, pinned Node 26.5.0, PERRY_GC_TRACE=1 PERRY_GC_DIAG=1:

corpus test	`PERRY_GC_HEAP_LIMIT=8` (default/incremental)	`+ PERRY_GC_INCREMENTAL=0`
`test_gap_repsel_canonical_i32`	0 cycles	3 cycles
`test_gap_repsel_ptr_shape_locals`	0 cycles	4 cycles

A trigger is due in both columns — turning incremental off collects, so the arming path agrees there is work. The difference is entirely in who runs the collection.

Mechanism

gc_check_trigger's direct-collection arm (the #5476 patch) is gated on registered_root_scanners_block_budgeted_gc(). Under gc_incremental_enabled() that predicate reduces to "is any copy-only scanner registered":

if super::gc_incremental_enabled() {
    return has_copy_only;
}

A compiled program registers none (copy-only scanners are the FFI copy-only API plus tests — the comment in gc/roots.rs says so). So the predicate is false, the direct arm is skipped, and the trigger is handed to the budgeted stepper, which is driven only by bounded mutator assists.

For an arena-triggered cycle #6977 made those assists scale: the debt term was reading the raw GC_NEXT_TRIGGER_BYTES cell instead of effective_next_arena_trigger() and therefore reported zero. For a malloc-triggered cycle the debt term is already correct —

malloc_debt_objects: malloc_count.saturating_sub(next_malloc_trigger)

— it is just small on a small program, so gc_mutator_assist_scaled_work_units() stays near its 256-unit floor and the cycle still never reaches completion. Same outcome, different cause: the cycle is started and then starved.

Why it matters

Correctness of the memory bound. "Started but never completed" is indistinguishable from "no collector" to RSS. This is the same shape as Memory not free in benchmark #5476 and as the debt-pacing regression fix(gc): a compiled program can now actually reach an evacuating minor (#6950) #6977 fixed; it keeps reappearing because the budgeted stepper has no completion guarantee, only a budget.
Every GC gate that runs on small programs is inert. scripts/gc_repsel_matrix.sh's default / verify_evac / gen_gc_off / wb_off / cons_scan_off arms require collect, and on 18 of 20 corpus files they get zero cycles in the shipped configuration. fix(gc): a compiled program can now actually reach an evacuating minor (#6950) #6977 made the move arms live by adding PERRY_GC_INCREMENTAL=0; the collect arms deliberately were not changed, because they are supposed to describe the shipped configuration — and the shipped configuration genuinely does not collect. That honest UNVER is this issue.

Suggested direction (not prescriptive)

The budgeted stepper needs a completion guarantee, not a bigger budget. Something shaped like: if a cycle has been active across N assists while its arming trigger is still due, finish it synchronously — the graceful degradation the pacing doc already describes ("under extreme allocation pressure incremental degrades gracefully toward synchronous behavior rather than toward unbounded memory"), applied to elapsed assists rather than to measured debt alone. A starvation counter is cheap and cannot regress the case where the cycle does complete on budget.

Whatever the fix, the acceptance signal is liveness, not a green table: PERRY_GC_TRACE=1 must show cycles > 0 for test_gap_repsel_canonical_i32 under PERRY_GC_HEAP_LIMIT=8 with no other GC env var set.

Related: #6950, #6977, #5476, #6180.

Full `--arms all` re-measure of the combination of today's 13 GC PRs

The last recorded matrix was taken immediately after #6977, before #6972/#6975, #6983, #6990, #6994, #7007, #6997 and #6974 landed. Each of those was verified against a different base, several within minutes of each other; nobody had measured the combination. This is that measurement.

Headline: the evacuating arms went from 14 red corpus files to 2, and there is not a single previously-green-now-red cell. The 180 UNVERIFIED cells this issue tracks are unchanged at 180 — none of the seven PRs touches the incremental stepper, and the measurement confirms it did not move by accident.

Setup


commit	`393a36aa4` (current `origin/main`; #7009/#7008 are its ancestors, PR numbers are not merge-ordered)
build	`--release`, `-p perry -p perry-runtime -p perry-stdlib -p perry-runtime-static -p perry-stdlib-static` (9m33s)
oracle	pinned Node 26.5.0 (asserted; the harness also hard-fails on any mismatch with `.node-version`)
command	`scripts/gc_repsel_matrix.sh --arms all --pressure 8 --jobs 6 --json` (`--pressure 8` = the script default and what #6977/#6981 used)
host	quiet mini, isolated worktree + isolated target dir

Freshness was verified functionally, not by mtime (CLAUDE.md stale-artifact trap). test_gap_gc_ta_ctor_source_rooting under the evacuating base is byte-exact with 6 558 objects copied — that cell failed before #6990 (literal: 0 undefined undefined), so a stale .a could not produce this result. The runtime archive also exports js_gc_temp_root_{push,set,get,truncate}.

Counts

summary: PASS=240  UNVER=199  XFAIL=1  FAIL=20     (460 cells = 23 corpus rows x 20 arms)
byte-exact vs node 26.5.0: 439/460

Delta vs 45 / 125 / 180 — and an honest note on the denominator

45+125+180 = 350, which matches no --arms all denominator in this window (20 corpus rows → 400 cells, 21 → 420, 22 → 440, 23 → 460 today). I cannot reconstruct that triple's exact population, so I am not going to publish a fabricated delta. What it fits cleanly is the 10 move arms plus the collect-arm inert block. Restricted to the 21 corpus rows that existed at #6977, so the comparison is apples-to-apples:

population	then	now
`move` arms (10 × 21) — PASS	45	179
`move` arms (10 × 21) — FAIL	125	20 (−84 %)
`collect` arms (9 × 21) — UNVER	180	180 (unchanged)

The 180 landing exactly on 180 is the load-bearing part for this issue: the collect arms are still inert on 21 of 23 corpus rows, and that is #6978 verbatim.

Per-cell: what changed on the evacuating arm

Diffed against #6981's recorded evac_minor column. 12 of the 14 previously-red cells are now green; nothing regressed.

corpus test	#6981 `evac_minor`	now
`repsel_canonical_i32`	FAIL SIGABRT	PASS (6 502 copied)	fixed
`specabi_polymorphic_coexist`	FAIL mismatch	PASS (6 511)	fixed
`specabi_reassign`	FAIL mismatch	PASS (6 509)	fixed
`ta_param_numeric_read`	FAIL SIGSEGV	PASS (6 551)	fixed
`typedarray_param_read`	FAIL SIGABRT	PASS (6 577)	fixed
`repsel_ptr_shape_locals`	FAIL SIGABRT	PASS (6 669)	fixed
`repsel_ptr_shape_barriers`	FAIL SIGSEGV	PASS (3 608)	fixed
`repsel_p4a_inline_tiers`	FAIL mismatch	PASS (3 585)	fixed
`repsel_p4a_logical_numeric`	FAIL mismatch	PASS (3 582)	fixed
`repsel_p4b_field_store_elision`	FAIL mismatch	PASS (6 611)	fixed
`repsel_proven_this_frozen`	FAIL SIGSEGV	PASS (3 632)	fixed
`repsel_gc_stress`	FAIL mismatch	PASS (1 026 015)	fixed
`repsel_p4a3_numarray_barriers`	FAIL	FAIL exit=139 (3 595)	still red
`repsel_p4a3_ptr_numarray`	FAIL mismatch	FAIL mismatch (6 513)	still red
`int_valued_ta_locals`, `specabi_recursion_escape`, `specabi_view_detach`, `repsel_canonical_str_locals`, `repsel_p4a_holes_axis`	PASS	PASS	unchanged
`repsel_p4a3_numarray_growth`	UNVER (0 moved)	UNVER (0 moved)	unchanged

Previously-green-now-red: none, and this is airtight

The red set today is exactly 20 cells: 2 corpus files × the 10 move arms. I rebuilt the #6977 baseline (e70ffe29d) and re-ran those same 10 arms on those rows through the same harness. Reverse-freshness on that build was proven first — #6981's own reproducer still prints after: undefined:

test \ arm                       evac_mi force_e force_v loop_po rep_i32 rep_str rep_ptr rep_ptr rep_spe rep_int
repsel_p4a3_numarray_barriers    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL
repsel_p4a3_ptr_numarray         FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL    FAIL

All 20 of today's red cells were already red at the baseline, on the same arms. Since a regression requires a cell that was green and is now red, and every red cell today is accounted for as already-red, the combination introduced zero regressions. That conclusion does not depend on the unmeasured cells, because a green cell cannot be a regression.

One retraction. I initially flagged numarray_barriers as having degraded from mismatch to crash, on the strength of #6981's table (mismatch (15 297)). My own re-measure at e70ffe29d gives exit=139 SIGSEGV, identical to today. The failure mode did not change; #6981's recorded entry for that one row disagrees with a direct re-measure at that commit. Withdrawing the concern.

Liveness — every arm, with evidence

  default              requires=collect  collected  2/23   moved-objects  0/23
  evac_minor           requires=move     collected 22/23   moved-objects 22/23
  force_evac           requires=move     collected 22/23   moved-objects 22/23
  force_verify         requires=move     collected 22/23   moved-objects 22/23
  loop_polls           requires=move     collected 22/23   moved-objects 22/23
  rep_i32_off          requires=move     collected 22/23   moved-objects 22/23
  rep_str_off          requires=move     collected 22/23   moved-objects 22/23
  rep_ptr_shape_off    requires=move     collected 22/23   moved-objects 22/23
  rep_ptr_numarray_off requires=move     collected 22/23   moved-objects 22/23
  rep_spec_abi_off     requires=move     collected 22/23   moved-objects 22/23
  rep_int_valued_off   requires=move     collected 22/23   moved-objects 22/23
  verify_evac / gen_gc_off / wb_off / gen_off_verify / wb_off_force /
  all_four / cons_scan_off / cons_scan_off_force
                       requires=collect  collected  2/23   moved-objects  0/23
  shipped_default      requires=none     collected  2/23   moved-objects  0/23

Largest copied_objects: scalar_replaced_locals 1 501 975, gc_stress 1 026 015. The evacuating arms are genuinely live — no green cell in this run comes from an inert arm.

Decomposition of the 240 PASS, so the number is not over-read:

199 on move arms with copied_objects > 0 — evacuation genuinely verified.
18 on collect arms, on the only 2 rows that collect (gc_stress, scalar_replaced_locals).
23 are shipped_default, whose requirement is none. It collected 0/23. Those 23 cells assert byte-exactness only and carry no GC evidence whatsoever — they should not be read as green GC results.

Still-UNVERIFIED: 199, and why

189 = this issue (gc: incremental mode starts a budgeted cycle and never completes it — a small compiled program still performs ZERO automatic collections (#6950 residue) #6978). The 9 collect arms are inert on 21 of 23 rows: the shipped incremental configuration performs zero collections on a small program. Not fixable by any rooting PR; it needs the budgeted stepper's completion guarantee.
10 = test_gap_repsel_p4a3_numarray_growth, which reports 0 cycles / 0 moved on every one of the 20 arms, including the evacuating base at --pressure 8. This is a corpus gap rather than a collector one: that file's churn budget never reaches a trigger, so its move cells assert nothing. Its cells have been honestly UNVER since the matrix landed and will stay that way until its allocation volume is re-tuned — same remedy the header prescribes for gc_stress.

The 2 remaining red cells → #6981

Both map to #6981, which stays open. Both are deterministic (8/8 trials, identical output) — not flakes, not harness-induced.

	`p4a3_numarray_barriers`	`p4a3_ptr_numarray`
symptom	SIGSEGV exit=139, dies inside `histogram()` before its 4th line	one lost update: index 27 reads `158` vs `159`, total `4999` vs `5000`
copied	3 595	6 513
conservative scan ON (control)	oracle-match, 3 527 copied	oracle-match, 3 518 copied
shipped config (control)	oracle-match	oracle-match

The #6981 discriminator reproduces exactly: both relocate thousands of objects and pass with the conservative stack scan on; they fail only under precise roots. Both are the identical source shape — counts[v] = (counts[v] || 0) + 1 over a new Array(size) local, with the collection driven by a neighbouring data.push(seed) loop.

New diagnostic worth recording: rep_ptr_numarray_off (PERRY_PTR_NUMARRAY_LOCALS=0) does not rescue either test — it is red on all 10 move arms including the representation's own off-switch. So the stale base pointer is not the Ptr<NumArray> promotion itself; #6981's remaining surface is the generic array element read-modify-write path. That should narrow the fix hunt considerably, and it distinguishes this from #6976 / #6984, which are off-switch defects.

The single XFAIL (ptr_shape_locals × rep_ptr_shape_off) is #6976, still correctly triaged.

Unrelated defect found: a duplicated corpus row

test-parity/gc_repsel_corpus.txt registers test_gap_repsel_proven_this_frozen twice — 23 rows, 22 unique. #6977 added it under "Phase 5a" near the top and again at the bottom. It is compiled and run twice per arm, inflating every count by 20 cells and double-weighting that one test in the liveness denominators (the 22/23 and 2/23 figures above). Harmless to the conclusions, but it should be de-duplicated so the totals mean what they say.

What I could not measure

Whether any of the 189 collect-arm cells would pass under a completed collection — that is precisely what gc: incremental mode starts a budgeted cycle and never completes it — a small compiled program still performs ZERO automatic collections (#6950 residue) #6978 blocks. No representation currently has any GC property verified in the shipped configuration.
I did not run a full --arms all at the fix(gc): a compiled program can now actually reach an evacuating minor (#6950) #6977 baseline (disk headroom on the host); I ran the targeted 10-move-arm × p4a3 subset. As argued above this is sufficient for the regression question, but it means I have no baseline figures for the cells that are green today.
numarray_growth asserts nothing on any arm, so all 20 representations remain unverified against that file's shape specifically.

fix(gc): charge the host-safepoint allowance per cycle, and keep it w…

Re-measured on current `main` (#7019 merged): this no longer reproduces

origin/main @ 4340bffc9 ("gc: default-on evacuating young-gen scavenge (moving minor at precise safepoints)", #7019). Release build of perry + perry-runtime + perry-stdlib + both -static wrappers, rustc 1.97.1, macOS arm64, oracle node 26.5.0 pinned. The compiler was built on one host and functionally re-verified on the host it ran on (byte-exact against the oracle before any measurement) — not trusted by mtime.

1. #6978's own acceptance line now passes

PERRY_GC_HEAP_LIMIT=8, PERRY_GC_TRACE=1, no other GC env var — the configuration this issue specifies:

test	#6978 as reported (pre-#7019)	current `main`	`+ PERRY_GC_INCREMENTAL=0`
`test_gap_repsel_canonical_i32`	0 cycles	1 cycle	2
`test_gap_repsel_ptr_shape_locals`	0 cycles	2 cycles	3

A/B'd through #7019's own kill switch, same source and same compiler, PERRY_GC_MOVING_LOOP_POLLS=0 set at both compile and run time (the codegen and runtime halves must agree):

config	canonical_i32	ptr_shape_locals
default (#7019 on)	1 cycle	2 cycles
#7019 off	0 cycles	0 cycles

So the symptom is gone, and #7019 is what removed it.

Mechanism (source-confirmed, and it is not a fix so much as a re-route). gc_moving_loop_polls_enabled() is now default-on, so gc_check_trigger enters its direct arm and an ArenaBytes / MallocCount trigger is taken away from the budgeted stepper before it can arm a cycle. There is no longer a budgeted cycle for nursery pressure to park in. The starvation path #6978 describes still exists in the code; nursery pressure simply no longer travels down it.

Both collections land mid-program — on an interleaved stdout/stderr stream the first [gc] cycle marker precedes the last program output line. That makes them stronger evidence than the teardown-boundary collections #7017 was filed against.

2. What that means for #7015

Its stated symptom no longer reproduces, so as a fix for this issue it looks obsolete and I'd close it — with two things kept:

fix(gc): a budgeted incremental cycle that nothing drives now completes (#6978) #7015's correction to this issue's text should outlive it. gc: incremental mode starts a budgeted cycle and never completes it — a small compiled program still performs ZERO automatic collections (#6950 residue) #6978's mechanism is wrong in both particulars: the trigger is ArenaBytes, not malloc (these programs never call gc_malloc; malloc_count=0 against a next_malloc=100000 trigger, so that path is never armed, not merely small), and the binding constraint was the number of gc_check_trigger opportunities — two in the whole process — not the assist budget's 256-unit floor.
The suppression hazard fix(gc): a budgeted incremental cycle that nothing drives now completes (#6978) #7015 identified is still live in the code. gc_safepoint_moving_minor still early-returns on gc_budgeted_cycle_active(), and so does gc_check_trigger's defer arm. A budgeted cycle armed by a non-nursery trigger would still park and would still disable gc: default-on evacuating young-gen scavenge (moving minor at precise safepoints) #7019's moving minor for the rest of the process. I did not construct that case. What I can say is that it does not occur on this corpus: in the shipped configuration test_gap_repsel_gc_stress performs 260 cycles with 251 [gc-copy-minor] ran and the last copy at line 1033 of 1038 — the moving minor keeps running to the end of the process. If fix(gc): a budgeted incremental cycle that nothing drives now completes (#6978) #7015 is closed, that guarantee is worth re-filing on its own merits rather than losing.

3. Matrix re-run — 440 cells / 22 rows (`--arms all --pressure 8`)

	PASS	UNVER	XFAIL	FAIL	byte-exact
pre-#7019 @ `4ad27a15b` (#7015's pre-fix arm)	229	190	1	20	419/440
current `main` @ `4340bffc9`	302	91	1	46	393/440
delta	+73	−99	0	+26	−26

The 190 UNVERIFIED moved wholesale — 99 of them left the column — but in both directions. The collect arms went from ~2/22 live to 13/22. I do not have the pre-#7019 per-cell JSON (only the aggregates in #7015's body), so I am not publishing a cell-by-cell transition table; the arm/row accounting below is what the +26 decomposes into.

4. ★ 26 newly-red cells. They are real, and both new rows are caused by #7019

row	arms	failure	#7019 ON	#7019 OFF	filed
`test_gap_repsel_gc_stress`	12	SIGSEGV	5/5 (23/23 across batches)	0/5 (0/11)	#7022
`test_gap_repsel_scalar_replaced_locals`	10	SIGSEGV, intermittent	11/20	0/20	#7023
`p4a3_numarray_barriers` + `p4a3_ptr_numarray`	10 → 12 each	#6981, +4 cells	—	—	commented on #6981

gc_stress was the corpus's green, live member (gc_repsel_triage.txt records its cons_scan_off cells as hard gates since #6951), so that is a PASS → FAIL regression, not an inert cell going red. It dies immediately after a successful evacuating minor (copied_objects=101215 promoted_objects=44933, fallback=none). scalar_replaced_locals is not #7018 — it faults with no PERRY_GC_TRACE and no PERRY_GC_DIAG at all.

Both failing sets are dominated by the same discriminator as #6981: the arms carrying PERRY_CONSERVATIVE_STACK_SCAN=off.

5. Per-arm liveness, with `copied_objects` separated from the C4b counter

The harness's moved figure sums two different collectors — moved_objects= (the mark-sweep C4b evacuation policy) and [gc-copy-minor] ran copied_objects= (#7019's scavenge). Separated, over all 22 rows:

arm	files with a cycle	files with `[gc-copy-minor] ran`	Σ copied_objects	Σ C4b moved
`default`	13/22	0/22	0	7 610 512
`verify_evac`	13/22	0/22	0	7 301 552
`gen_gc_off`	13/22	0/22	0	0
`gen_off_verify`	13/22	0/22	0	0
`cons_scan_off`	13/22	13/22	21 767 487	0
`cons_scan_off_force`	13/22	13/22	3 584 101	0
`evac_minor`	21/22	21/22	3 628 777	0
`force_evac`	21/22	21/22	21 800 212	0
`force_verify`	21/22	21/22	21 816 708	0
`shipped_default` (no env)	2/22	2/22	40 087 037	0

Two things fall out, both filed:

The default arm runs zero copying minors on all 22 rows — --pressure 8 collapses gc_moving_defer_hard_cap_dyn_bytes() and the arena-trigger ceiling to the same budget_scaled(_, 1, 4, 2 MB) value, so arena_total_bytes() < hard_cap is false exactly when the trigger fires and the defer arm is skipped ([gc-copy-minor] eligible=false fallback=conservative_stack). Sweeping the knob on canonical_i32/ptr_shape_locals: limits 2 and 8 give cycles but zero copy-minors, limits 16/32/64/128 give zero cycles at all. The band is empty. → gc-matrix: --pressure disables the very path #7019 added — the 'default' arm runs ZERO copying minors on all 22 corpus rows #7024
The conflated moved counter lets a requires=move arm be green with zero scavenged objects. → gc-matrix: the 'moved' liveness counter sums the C4b mark-sweep evacuation with the copying minor, so a move-arm can be green with zero scavenged objects #7025

The un-pressured shipped default does work as advertised: 251 copy runs, fallback=none, 13 501 581 objects copied on gc_stress.

test_gap_repsel_p4a3_numarray_growth is 0 cycles / 0 copies in every arm including evac_minor, which is #7016 exactly — 19 of the 91 remaining UNVER cells are that one row.

6. Things I got wrong along the way, and corrected

Recorded because they are cheap to repeat:

An early "control" run reported 0/15 failures for rows the matrix said were red. It was invalid: those loops ran under zsh, which does not word-split an unquoted $E, so env $E binary set a single garbage variable and the GC env vars were never applied — the control was silently measuring the shipped default. Re-run under bash, the failures reproduce.
A second batch counted exit 127 (binary did not exist) as a crash, producing a fake "5/5 crashes" for scalar_replaced_locals. Retracted; the numbers in §4 are from re-measurement with explicit exit codes.

7. Not measured

A cell-by-cell pre/post diff (no pre-gc: default-on evacuating young-gen scavenge (moving minor at precise safepoints) #7019 per-cell JSON exists anywhere I could find).
A constructed parked-budgeted-cycle scenario to test the gc_safepoint_moving_minor suppression directly — only the observation that it does not occur on this corpus.
gc: PERRY_GC_TRACE=1 SIGSEGVs under the evacuating arms — the liveness instrument crashes on the corpus file that most needs it #7018's own crash: my liveness instrument does fault on some rows under the evacuating arms. Liveness for those rows is still established, because the crash reproduces without the instrument.

Status update: the symptom is gone, but this issue's stated mechanism is wrong and one hazard survives

PR #7015 (the fix) has been closed as obsolete — see its closing comment for the measurements. Summary here so this issue is self-contained.

The symptom no longer reproduces

Re-measured on 4340bffc9 (post-#7019, default-on evacuating young-gen scavenge), on this issue's own acceptance rows:

row	before	now
`test_gap_repsel_canonical_i32`	0 cycles	1
`test_gap_repsel_ptr_shape_locals`	0 cycles	2

PERRY_GC_MOVING_LOOP_POLLS=0 restores 0/0, attributing the change to #7019. It removed the starvation by re-routing nursery triggers away from the budgeted stepper before a cycle can arm — not by fixing the completion path. Both collections now land mid-program, not at teardown (cf. #7017).

★ This issue's mechanism is wrong in both particulars

Correcting the text above, because it will otherwise keep misdirecting readers:

Not malloc-triggered. The trigger is ArenaBytes. The two programs named in this issue never call gc_malloc at all — malloc_count=0 against a next_malloc=100000 trigger. The malloc path was not "small"; it was never armed.
The assist budget was never the binding constraint. gc_check_trigger runs exactly twice in the entire process. The second call arms the cycle, pays one assist, and no allocation-point opportunity ever comes again (3 arena blocks total). The 7 steps that follow are host safepoints at the fixed 2048-unit slice; they reach RootScan and the process exits. A fatter per-step budget could not have fixed this — completion needs a bounded number of calls, not more units.

What this issue should stay open for

gc_safepoint_moving_minor early-returns on gc_budgeted_cycle_active(), so a parked budgeted cycle disables the moving path for the rest of the process. #7019 removed the nursery-armed route into that state, but a non-nursery-armed budgeted cycle could still reach it.

Not observed on the repsel corpus (gc_stress: 251 copy runs, last at line 1033/1038), and not constructed — so this is a live hazard with no reproducer, which is the hardest kind to keep honest.

Per the GC knob kill-policy now in CLAUDE.md (every GC knob either has a required CI arm exercising its off-state, or it is deleted after one release of soak), the resolution is one of:

add an arm that reaches a non-nursery-armed budgeted cycle and asserts the moving minor still runs; or
remove the early-return once the moving path is unconditional, so the state cannot exist.

A reachable state with no test covering it is exactly what that policy is meant to eliminate.

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

This issue's own stated acceptance signal is cycles > 0 for test_gap_repsel_canonical_i32 under PERRY_GC_HEAP_LIMIT=8 with no other GC env var set. Measured, PERRY_GC_TRACE=1, compiled with no compile-time GC env:

configuration	cycles
`PERRY_GC_HEAP_LIMIT=8` only	0
`+ PERRY_GC_INCREMENTAL=0`	1

Unchanged from the table here. A trigger is due in both columns — turning incremental off collects — so the arming path still agrees there is work and the budgeted stepper still never finishes the cycle it starts.

Worth connecting to #7255, which measured the downstream consequence corpus-wide rather than on two files: the requires=scavenge arms (default, verify_evac, cons_scan_off, cons_scan_off_force) now report copy-minor 0/49. This issue's point 2 — "every GC gate that runs on small programs is inert", and the honest UNVER is this issue — is now the state of four of the six PR-gating arms, not just of the --arms all table.

The suggested direction (a completion guarantee via a starvation counter rather than a bigger budget) still looks right and is untouched in the tree.

Closing — measured on v0.5.1414 and the observable does not reproduce.

What I ran

A compiled program allocating class N { v: number; s: string } in a loop, PERRY_NO_AUTO_OPTIMIZE=1, no zeal, no loop polls — i.e. the default configuration this issue is about.

workload	automatic collections
400k allocations (~36.7 MB)	0
4M allocations (~133–150 MB freed per cycle)	12 diag lines, multiple `[gc]` cycles, peak RSS 201 MB

And all three incremental arms behave identically at 4M: unset → 12, PERRY_GC_INCREMENTAL=1 → 12, PERRY_GC_INCREMENTAL=0 → 12.

The 400k case is correct behaviour, not the bug. It frees 36.7 MB against a 64 MB initial arena trigger threshold, so it never reaches a trigger. "A small program performs zero automatic collections" is true of any program that stays under the threshold, by design.

The control, because a zero is worthless without one

0 diag lines could equally mean the diag knob prints nothing. It does not: the same binary with an explicit gc() prints 3 lines ([gc] blocks: …, [gc-old-free], [gc-tenuring]), and with PERRY_GC_MOVING_LOOP_POLLS=1 + PERRY_GC_ZEAL=1 prints 22. The instrument works; the small program simply does not collect because it should not.

Why this issue was hard to settle by reading

It is the clearest instance I have seen of a claim that silently stopped being true, and the history is worth keeping:

the original diagnosis was retracted by its own author (wrong trigger counter, wrong model of when the budgeted stepper runs);
the PR meant to fix it (fix(gc): a budgeted incremental cycle that nothing drives now completes (#6978) #7015) was closed as obsolete, not merged, because gc: default-on evacuating young-gen scavenge (moving minor at precise safepoints) #7019 fixed the observable by a different mechanism;
5a06970b6 ("disable evacuating minor by default pending GC: evacuating minor drops an old-to-young field[1] edge, crashing with 'value is not a function' #7154") plausibly re-broke it;
fix(gc): restore evacuation at precise safepoints — the pacing half of #7682 #7690 ("restore evacuation at precise safepoints") plausibly re-fixed it, landing hours before this measurement.

Four changes of state, none of which updated the issue. Any percentage or behaviour claim attached to this ticket that predates today should be treated as unverified.

If automatic collection genuinely fails on a workload that does exceed the threshold, please reopen with that workload and a PERRY_GC_DIAG=1 capture — the diag-line count against a known-good control is the whole test.

gc: incremental mode starts a budgeted cycle and never completes it — a small compiled program still performs ZERO automatic collections (#6950 residue) #6978

Description

Symptom

Mechanism

Why it matters

Suggested direction (not prescriptive)

Activity

proggeramlug commented on Jul 29, 2026

Full --arms all re-measure of the combination of today's 13 GC PRs

Setup

Counts

Delta vs 45 / 125 / 180 — and an honest note on the denominator

Per-cell: what changed on the evacuating arm

Previously-green-now-red: none, and this is airtight

Liveness — every arm, with evidence

Still-UNVERIFIED: 199, and why

The 2 remaining red cells → #6981

Unrelated defect found: a duplicated corpus row

What I could not measure

proggeramlug commented on Jul 29, 2026

Re-measured on current main (#7019 merged): this no longer reproduces

1. #6978's own acceptance line now passes

2. What that means for #7015

3. Matrix re-run — 440 cells / 22 rows (--arms all --pressure 8)

4. ★ 26 newly-red cells. They are real, and both new rows are caused by #7019

5. Per-arm liveness, with copied_objects separated from the C4b counter

6. Things I got wrong along the way, and corrected

7. Not measured

proggeramlug commented on Jul 30, 2026

Status update: the symptom is gone, but this issue's stated mechanism is wrong and one hazard survives

The symptom no longer reproduces

★ This issue's mechanism is wrong in both particulars

What this issue should stay open for

proggeramlug commented on Aug 2, 2026

proggeramlug commented on Aug 9, 2026

What I ran

The control, because a zero is worthless without one

Why this issue was hard to settle by reading

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Full `--arms all` re-measure of the combination of today's 13 GC PRs

Re-measured on current `main` (#7019 merged): this no longer reproduces

3. Matrix re-run — 440 cells / 22 rows (`--arms all --pressure 8`)

5. Per-arm liveness, with `copied_objects` separated from the C4b counter