Repository navigation
GC ratchet has broad deterministic fingerprint shifts that need attribution #8051
Description
Failure
The scheduled GC ratchet now produces deterministic counter fingerprints that differ substantially from the pinned baseline across roughly twenty rows. This is not a one-row/noise-shaped failure and must be attributed before any re-pin.
Exact evidence: run 31734917043 / gc-ratchet job 94564108190, head 3381e1b89048592cfc91f3d4a43349c6e7c16015. Duplicate samples in the artifact agree, making host jitter an inadequate explanation for the counter deltas.
Representative shifts from the job's pinned-baseline comparison:
| workload | counter | pinned | current | delta |
|---|---|---|---|---|
| survivor-heavy | copied objects | 35,943 | 44,539 | +23.92% |
| cross-gen | copied objects | 8,214 | 4,107 | -50.00% |
| cross-gen | copied bytes | 656,256 | 262,592 | -60.00% |
| shape-heavy | heap-used bytes | 12,419,456 | 21,516,800 | +73.27% |
| async-heavy | copied objects | 13,013 | 241 | -98.15% |
Other rows shift copied/promoted/freed bytes in both directions. The current pinned file is therefore not being updated as part of freshness triage.
Required investigation
- Compare the baseline capture SHA and current source/runtime configuration, then attribute each coherent shift cluster to a collector, allocation-layout, or workload change.
- Classify attributed changes as regression or accepted mechanism evolution with source evidence and a local same-binary repeat.
- Re-pin only the accepted rows, with the attribution recorded alongside the new capture.
Acceptance
- No unexplained row is hidden by widening thresholds or wholesale baseline replacement.
- Regressions are fixed and locally remeasured; accepted mechanism changes get a reviewed, reproducible baseline update.
- Sabotage/self-tests still demonstrate that the ratchet rejects a meaningful counter regression.
Activity
proggeramlug commentedon Aug 13, 2026
The pinned artifact is not a current-source baseline. Its provenance is:
The repin commit (#7921) explicitly accepted #7886/#7888/#7895. Between that capture and current head, several changes directly alter the counters that are now red:
f110261a4(perf(runtime): right-size small objects — INLINE_SLOT_FLOOR 4 -> 2 (#7916, #7714) #7928):INLINE_SLOT_FLOOR 4 -> 2, changing object sizes/allocation cohorts.a87bf3e3f(fix(gc): denominate the nursery constant band in objects (#7929) #7961): denominates the nursery constant band in surviving objects.c35234de2(perf(gc): let the first copying minor decide its promotion from its own trace (#7937) #7960): lets the first copying minor retain an in-place promotion based on its own trace.0a21611fe(fix(gc): credit every promotion to the old-reclaim baseline, untraced or not (#7965) #7968): credits every promotion to old-reclaim pacing.17da9aabb(fix(gc): do not start a budgeted cycle for a nursery-cap trigger it cannot discharge (#7909) #7972): changes nursery-cap trigger admission.5ade8722a(perf(gc): skip descriptor probes for plain typed stores #8023) and971d6ffb6(fix(gc): install array growth forwarding for low-address arenas #8041): change typed-store/array-growth GC behavior.These are plausible attribution groups, not permission to re-pin. In particular, the current artifact came from a 3-vCPU virtual M1 runner (
load_average 17.1/26.81/20.57) while the pinned capture is a physical M1 mini, but duplicated current samples agree; deterministic collector counters should be re-run on the pinned host before using host load to dismiss any row.Next evidence needed remains a same-binary repeat on the pinned mini plus per-change attribution of the coherent row groups. No baseline changes are included in the gate-freshness fixes.