GC: copying minor reports not_attempted on every cycle in the memory-stability gates; old_page_forced_defrag moved > selected #9659

Activity

1. proggeramlug commented on Sep 3, 2026

   

   proggeramlug

   on Sep 3, 2026

   ContributorAuthor

   More actions

   Resolved: this is a mis-specified gate, not a collector regression

   Pulled the per-workload numbers out of the evidence artifact. The correlation is exact:

   workload	sets PERRY_GC_FORCE_EVACUATE=1	cycles	not_attempted	copied	promoted
   async_promise_closures	yes	10	5	486,088 B	158,648 B
   default_copying	no	8	8	0	0
   string_heavy	no	4	4	0	0
   closure_heavy	no	5	5	0	0
   large_object_barriers	no	4	4	0	0
   raw_numeric_layouts	no	3	3	0	0

   The five failing workloads are exactly the five that do not set the knob, in workload_specs in run_target_collector_architecture_gates.

   The copying minor is healthy. async_promise_closures copies 486 KB and promotes 159 KB, and pointer_free_numeric copies 528 B with not_attempted=0.

   Why the other five report not_attempted on every cycle

   Their raw traces show every collection is an explicit one:

   "collection_kind":"full"
   "progress_kind":"explicit_full"
   "reason":"explicit_or_emergency"
   "arena":{"in_use_bytes":6408}

   The whole heap is 6.4 KB, so nothing ever reaches nursery pressure — every collection comes from an explicit gc(). Per CLAUDE.md, a manual gc() runs a full mark-sweep and only runs an evacuating minor first when PERRY_GC_FORCE_EVACUATE=1 is set (#6946). These five set neither the knob nor enough allocation to trigger a natural minor, so the copying minor is correctly not_attempted — and the gate then fails them for it.

   So the assertion is unconditional while the configuration that satisfies it is per-workload. That is a category error in the gate, not a defect in the collector.

   Note on why it surfaced now

   This runs only at test.yml:2837 inside compile-smoke, full tier only. Runs 33626738093 and 33709074616 both died at step 8 and never reached it, so the gate has been dark for months.

   Options

   1. Scope the assertion to workloads that force evacuation — the copying-minor assertion stays fully in force wherever a copying minor is actually exercised, and stops being applied where one cannot occur. Minimal and correct.
   2. Add PERRY_GC_FORCE_EVACUATE=1 to the other five — broadens real copying coverage, and is what the gate seems to have intended. Higher value, but it makes five workloads newly exercise evacuation, which may surface genuine findings; that deserves its own change rather than riding a release.

   old_page_forced_defrag's old_page_moved_bytes(80) > old_page_selected_live_bytes(32) is unrelated to the above and still stands as a real accounting inconsistency.
2. proggeramlug commented on Sep 3, 2026

   

   proggeramlug

   on Sep 3, 2026

   ContributorAuthor

   More actions

   Correction: the inversion is real, but inverting it is NOT the fix

   I tried the obvious repair — flip target_gates_require_copied_minor so the requirement lands on the workload that forces evacuation — and ran it against this run's real report. It only moves the failure:

   async_promise_closures: fallback reasons other than none: {'not_attempted': 5}
   async_promise_closures: copied-minor ineligible cycles=5
   async_promise_closures: malloc_registry_rebuilds=1, want 0
   

   Reverted; nothing proposed from it.

   The actual contract problem

   The strict block asserts three separate things:

   assertion	demands
   fallback reasons other than none	every cycle attempted a copying minor
   ineligible_cycles == 0	every cycle was eligible
   copied_objects + promoted_objects > 0	at least one cycle moved something

   The third is the meaningful "the subject was live" check. The first two demand that 100% of collections in the workload be copying minors — which no workload here satisfies:

   • async_promise_closures attempts copying on 5 of 10 cycles (and copies 486,088 B, promotes 158,648 B) → fails the first two.
   • The other five attempt it on 0 of N → fail all three.

   So no workload in the suite can pass the strict block as written, whichever way the predicate points. That is the real defect, and it is larger than a predicate flip.

   What is established

   • The collector is healthy. async_promise_closures copies 486 KB and promotes 159 KB; pointer_free_numeric copies 528 B with not_attempted=0.
   • not_attempted on the non-forcing workloads is correct behaviour, not a regression: they drive collections purely through explicit gc() on a ~6.4 KB heap (collection_kind=full, progress_kind=explicit_full on every cycle), and gc() only evacuates first when the knob is set (GC testing: PERRY_GC_FORCE_EVACUATE is inert for gc()-driven tests (full mark-sweep + forced conservative scan) — stress claims may be unsupported #6946).
   • The gate has been dark for months (full tier only, and the last two cycles died before reaching it), so this contract has not been exercised in a long time.

   What the fix needs to decide (maintainer call)

   1. Should a workload be allowed to mix full sweeps with copying minors — i.e. should not_attempted / ineligible_cycles be tolerated while still requiring productive > 0 and still failing on real fallback reasons (conservative_stack, pinned_young_*, barriers_inactive)? That looks right to me, but it changes what the gate promises.
   2. Should the five non-forcing workloads get PERRY_GC_FORCE_EVACUATE=1 so they genuinely exercise copying, rather than being exempted?
   3. async_promise_closures: malloc_registry_rebuilds=1, want 0 is a separate assertion that also fails and needs its own answer.

   I am deliberately not guessing at these on a release pin.
3. TheHypnoo

   added

   performanceRuntime, compile-time, build-size, or memory performanceRuntime, compile-time, build-size, or memory performance

   on Oct 26, 2026