Skip to content

gc-matrix: test_gap_repsel_p4a3_numarray_growth never crosses a GC trigger, so all 19 of its GC cells assert nothing #7016

Description

@proggeramlug

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.

Refs #6978, #7015, #6950.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions