Repository navigation
gc-matrix: test_gap_repsel_p4a3_numarray_growth never crosses a GC trigger, so all 19 of its GC cells assert nothing #7016
Description
Split out of #6978 (fixed in #7015).
test_gap_repsel_p4a3_numarray_growth is the one corpus row that is still UNVER on every GC arm of scripts/gc_repsel_matrix.sh --arms all --pressure 8 after #7015 — 19 of the 19 remaining unverified cells are this single file.
It is not a collector defect. The file performs zero collections in every configuration:
| configuration | cycles |
|---|---|
PERRY_GC_HEAP_LIMIT=8 (matrix default arm) |
0 |
PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 |
0 |
PERRY_GC_HEAP_LIMIT=2 |
0 |
PERRY_GC_DIAG=1 prints nothing at all — the arena trigger never arms, because the test allocates under one 1 MB arena block and makes no gc_malloc calls. PERRY_GC_HEAP_LIMIT cannot lower the trigger further: gc_trigger_absolute_ceiling_bytes is budget/4 with a floor, so 2 MB is already the bottom.
So its 19 move/collect cells assert nothing about Ptr<NumArray> growth under GC, which is exactly the false confidence the matrix exists to remove — the honest UNVER is the gate working, and the fix is on the test side.
Action: give the file enough escaping allocation churn to cross a trigger under --pressure 8, the way test_gap_repsel_gc_stress does, while keeping it a growth-path test (it needs to hold a Ptr<NumArray> local live across a push-driven reallocation while the collector runs). The other Phase 4a.3 members (p4a3_numarray_barriers, p4a3_ptr_numarray) already collect 1-2 cycles, so this is a churn-budget gap in one file rather than a category problem.
Activity
proggeramlug commentedon Aug 2, 2026
Confirmed still open on
main=d4ac65f21. Re-verified in the sweep #7262.test_gap_repsel_p4a3_numarray_growth, compiled with no compile-time GC env,PERRY_GC_DIAG=1, three configurations:PERRY_GC_HEAP_LIMIT=8(matrixdefault)PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0PERRY_GC_HEAP_LIMIT=2Matches this issue's table exactly — the file performs zero collections in every configuration and
PERRY_GC_DIAG=1prints nothing at all. Its GC cells still assert nothing.The action is unchanged and is on the test side, not the collector's. One caveat on sizing the work now: per #7255, the
requires=scavengearms run zero copying minors on every corpus file, not just this one — so fixing this file's churn budget will make it live on therequires=movearms only, and the 19-cell figure will not fully clear until #7255 is resolved.proggeramlug commentedon Aug 9, 2026
Fixed in #7676. The probe was at fault, exactly as this issue diagnosed — reproduced before changing anything:
Sections 1–5 are untouched so their 'fully contained, therefore promoted' shape is unchanged; a section 6 adds
test_gap_repsel_gc_stress's escaping module-level churn sink, with thePtr<NumArray>local initialized before the churn, grown bypushpast several capacity doublings while it runs, and read after it in the same iteration.Measured on all 13 arms — PASS on every one, output byte-identical to the pinned Node 26.5.1 oracle in each.
default4 cycles / 74,404 objects copied;gen_gc_offand the othercollectarms 7 cycles;shipped_defaultstill 0, as its control role requires.Per #7666 the check is on the copying minor specifically, not merely on a cycle —
arena_growth_full_escalation_duewill escalate every minor to a full sweep on a large Eden over a small retained set, which is a live way for a probe to allocate heavily and still reach nothing.fix(gc-matrix): give the numarray-growth probe churn that reaches the…
fix(gc-matrix): give the numarray-growth probe churn that reaches the…
fix(gc-matrix): the collect arms require a productive cycle, and the …