docs: record plan status after statepoints landed, and what blocks adoption - #7318
Merged
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR updates GC architecture documentation and the changelog with landed statepoint status, adoption blockers, validation results, limitations, and the shipped ChangesGC statepoint adoption status
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
✨ Finishing Touches🧪 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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Records where the plan stands after layers 0 and 2 landed, and — more usefully — what does not follow from them.
What #7314 establishes: every root path fails closed (the plain-stackmap fallback deleted, not kept, after it was found surviving in three places that all failed open); metadata re-encoded 4,214,384 → 224,832 B (18.7×), the dominant lever being that 77% of records share the previous record's live set; and 23,301/23,301 safepoints emitted as statepoints with zero fallbacks.
What it does not: binary size is a wash, not a win, and the author is explicit that closing that axis needs fewer roots, not tighter encoding. And statepoints describe emitted frames only — hand-written runtime Rust (layer 3) is untouched, which matters because that is exactly where #7280's fault has already moved (
js_native_call_method + 580).Three things block adoption, none of them code:
PERRY_STATEPOINTSis exercised bygc-native-roots.yml;PERRY_RS4GC,PERRY_GC_SAFEPOINT_ONLY,PERRY_STACKMAP_WALKERandPERRY_STATEPOINT_REPORTappear in no workflow at all. The PR author flagged this themselves.gc-native-rootsis not a required context — reports without blocking.function.rs847 → 2036,linker.rs1936 → 2082 — solintnow fails two gates. Both are visible only because ci(lint): let every gate report instead of stopping at the first failure #7306 made gates report independently; before that, one red gate concealed the rest.Docs only.
Summary by CodeRabbit