perf(gc): promote a fully-live young generation without tracing it — retain −33.6%, deeplist −43% - #7888
Conversation
A copying minor that promotes the WHOLE young generation in place still ran the full trace: the remembered-set dirty scan marked every survivor, the drain re-touched every marked header, and clear_marks touched them a third time — three passes over a cohort far larger than any cache, on a cycle where nothing moves and nothing can be freed. After retag_young_for_in_place_promotion no address in the heap classifies as Nursery, so move_young is unreachable, no remembered-set entry can be created (#7744's skip_remembering proof), and the address-keyed death-pruning passes find nothing by construction. That leaves the marks with two real consumers: the old-gen page index's live filter, and the survival ratio itself. So skip the trace when the last MEASURED ratio is in the fully-live regime (>= 999 permille), registering every object on the promoted block instead of only the marked ones, and charge the promoted bytes against a budget that forces a measuring cycle before the assumption can run away.
…n progress An allocate-black birth puts GC_FLAG_MARKED on a nursery object. A cycle that neither reads nor clears marks would carry that bit into old-gen, where a stale mark reads as live to the next full sweep.
…the last measurement Comparing against the CURRENT figure compares a quantity with itself — the untraced bytes are old-gen bytes — so the relative half could never fire.
…ment implies Charging zero is not "no garbage", it is "no answer" — and it disarmed the 32 MB footprint cap for the whole untraced run. Both paths now feed the same cap; they differ only in whether the dead figure is measured or extrapolated.
|
Warning Review limit reached
Next review available in: 21 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
📝 WalkthroughWalkthroughAdds untraced whole-young-generation promotion when the last survival measurement is fully live. The runtime adds budget controls, safety vetoes, all-object indexing, promotion metrics, diagnostic fields, and tests for thresholds, resets, and later evacuation. ChangesUntraced Promotion
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant CopyingCollection
participant PromoteInPlace
participant PromotionIndex
participant GCDiagnostics
CopyingCollection->>PromoteInPlace: check policy and instrumentation
PromoteInPlace-->>CopyingCollection: select traced or untraced cycle
CopyingCollection->>PromotionIndex: finalize promotion with liveness mode
PromotionIndex-->>CopyingCollection: register promoted objects
CopyingCollection->>PromoteInPlace: record bytes and counters
CopyingCollection->>GCDiagnostics: emit cycle diagnostics
Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/perry-runtime/src/gc/tests/promote_in_place.rs`:
- Around line 280-376: Extend
an_untraced_promotion_indexes_the_objects_it_could_not_prove_live with a second
allocation on the promoted block that is not rooted before the first collection.
Verify during the subsequent evacuating collection that this unrooted object was
indexed and remains discoverable, preferably by storing a young child through it
and asserting the child is copied and relocated; keep the existing rooted parent
assertions intact.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 607400c9-074f-4912-9034-0d2e60ee7da4
📒 Files selected for processing (8)
changelog.d/7888-untraced-whole-block-promotion.mdcrates/perry-runtime/src/arena/mod.rscrates/perry-runtime/src/arena/promote.rscrates/perry-runtime/src/gc/barrier/mod.rscrates/perry-runtime/src/gc/copying.rscrates/perry-runtime/src/gc/mod.rscrates/perry-runtime/src/gc/promote_in_place.rscrates/perry-runtime/src/gc/tests/promote_in_place.rs
1 participant
What
A copying minor that promotes the whole young generation in place (#7742) still ran the
full trace. It does not any more, when the last measured young-survival ratio says the
nursery is fully live.
Measured per phase with
PERRY_GC_TRACE=1ongc-handoff/bench/retain.ts, per promotingcycle:
copying_nursery(the trace)in_place_promotion(the promotion)The promotion is ~9 ns/object. The trace alongside it is ~55–67 ns/object. The per-object
cost of "whole-block in-place promotion" was never the promotion.
Why it is safe to drop
retag_young_for_in_place_promotiontakes every in-use Eden and survivor block, so afterit no address in the heap classifies as
Nursery. Therefore, on such a cycle:move_youngis unreachable — nothing moves — so every root walk, slot rewrite andforwarding repair is a provable no-op rather than an approximation;
skip_rememberingproof, reusedverbatim as a precondition here), so clearing the whole remembered set is exact;
dead_owner::owner_is_dead, the map/set/errorfinalizers) all require the owner to classify as
Nurseryon a minor, so they alreadyprune nothing.
That leaves the marks with two real consumers: the old-gen page index's live filter, and the
survival ratio itself.
PromotionLiveness::AssumeAllLive— register every parseable objecton the promoted block. Registering a dead object is safe and is closer to what the index is
for (it answers "which objects are on this page"); the next full mark-sweep frees and
unregisters it. The cost is accounting precision, not correctness.
UNTRACED_PROMOTED_BYTESis charged peruntraced cycle and capped at
max(128 MB, old-gen at the last measurement); exceeding itforces the next cycle to trace, which re-arms or disarms. A full collection resets it. The
dead bytes the last measurement implies are charged to the existing 32 MB
PROMOTED_DEAD_BUDGET_BYTES— charging zero is not "no garbage", it is "no answer", and itwould disarm that cap for the whole run.
The path refuses to run when any assumption is not free: a registered weak-target holder
(weak tombstoning reads marks), a non-empty malloc registry (the malloc sweep reads marks),
an incremental mark in progress (an allocate-black birth puts
GC_FLAG_MARKEDon a nurseryobject, and a cycle that neither reads nor clears marks would carry it into old-gen where a
stale mark reads as live), or
PERRY_GC_VERIFY_EVACUATION/PERRY_GC_FROMSPACE_SCAN/PERRY_GC_VERIFY_MARK— each of those instruments takes the trace as its subject, and acycle producing no marks would let all three report success having examined nothing.
PERRY_GC_PROMOTE_IN_PLACE=0still turns the whole family off.Measured — quiet M1 mini, best-of-5, exit-checked, window quiet at both ends
Both arms built by me from
9ca8b4f71; both corpora 19/19 byte-identical to node + exit 0before timing (including
shapes, which is what caught the last round's silent wrong answer).ns per promoted object (Σ
pause_us÷ Σpromoted+copied, second token-guarded window).Handled-object counts are identical to the object in both arms on every benchmark — the
collector does the same amount of promotion, it just stops tracing to decide it:
Peak RSS: no regression —
retain−5.1 MB,retain_wide−4.2 MB,retain1−11.8 MB,retain_wide1−12.6 MB,shapes−1.2 MB;deeplist+0.9% andchurn+0.4%.pipeline+3.3% is real (re-measured in the second window) but it runs zero untracedcycles and has identical handled counts, so the mechanism is not this path — most likely
runtime code layout. It is the only cell outside ±0.6%.
The risk, measured rather than argued
gc-handoff/bench/phase_flip.ts: 1.5 M records retained (which arms the path), then 6 Mchurned. Output byte-identical to node on both arms. Peak RSS 263 MB → 370 MB.
That is the designed exposure and its bound working: main disarms on the flip cycle itself
(it measures 174‰); this branch promotes one more nursery untraced and the budget then forces
the measuring cycle that disarms it (measuring 0‰). The cost is that the flip is noticed
one cycle later, bounded by the floor constant. The floor is a real trade, not a free
parameter:
retain's untraced run reaches 97.4 MB, so any floor below ~100 MB costs it ameasuring cycle on its largest nursery and puts
retainback at ~0.19.Tests
gc/tests/promote_in_place.rs(4 new). The load-bearing one,an_untraced_promotion_indexes_the_objects_it_could_not_prove_live, stores a young childinto an untraced-promoted parent and forces the NEXT cycle to evacuate — on a promoting
cycle every young object survives whether or not anything reached it, so without that the
test would pass against a promotion that indexed nothing. It is sabotage-verified:
flipping
AssumeAllLive => falsefails it withcopied_objects 0 != 1.cargo test --release -p perry-runtime --lib(RUST_TEST_THREADS=1): 2129 passed, 0 failed.shapes) under
PERRY_GC_SCHEDULE_RATE=1andPERRY_GC_PROTECT_FROMSPACE=1 +DEPTH=800—neither vetoes it, and 4 untraced cycles still fire under both — plus
PERRY_GC_VERIFY_EVACUATION=1andPERRY_GC_FORCE_EVACUATE=1, which DO veto it by design.All outputs correct.
iso_misscanarychecksum 437840 misses 0with the instrumentconfirmed live (50
[gc-fromspace-protect]lines) — thoughiso_missruns zero untracedcycles, so it is evidence about the rest of the collector, not about this change.
What this does NOT reach
The brief's targets (
retain≤ 0.16,retain_wide≤ 0.20) are not met. What is left istwo structural items:
retain(an evacuation of 247 346 objects, ~24 ms of the remaining 51.7 ms). It cannot promote in
place because nothing has been measured yet —
LAST_YOUNG_SURVIVAL_PERMILLEisNone,which is a different state from a measured 0 and is asserted as such by
an_unmeasured_thread_never_promotes. Making it bet would cost everychurn-shapedprogram one nursery of retained garbage at startup.
put
GC_FLAG_TENUREDon every promoted header, which the generated write barrier's fastpath reads (perf(gc): write barriers cost 16% on an all-numeric store workload — elide on provably-non-pointer stores #7511). Removing it means giving the barrier a page-based generation test
instead of a header bit — which is what lets V8's page promotion be genuinely O(1).
retain_wideadditionally has a mutator half of ~172 ms against node's 157 ms for the wholeprogram, so
retain_wide ≤ 0.20requires GC ≤ 28 ms — below what any design touching oneheader line per object over ~390 MB can reach.
Summary by CodeRabbit
New Features
Bug Fixes
Tests