fix(ci): point the thread-local ratchet at cycle_malloc_trim.rs (main is red, blocking all PRs) - #9268
Conversation
`main` is red on `self-test-checkers`, which blocks the check on every open
PR. Reproduced against a pristine `origin/main` worktree, so it is not any
one PR's diff:
crates/perry-runtime/src/gc/cycle_malloc_trim.rs: 1 raw `thread_local!`
block(s), none allowed.
crates/perry-runtime/src/gc/cycle.rs: recorded as having 1 cold
`thread_local!` block(s), but has none.
Both halves are the same event. PerryTS#9245 (mine) added 20 lines to `cycle.rs`,
which pushed it past the 2000-line cap, so the merge split
`cycle_malloc_trim.rs` out of it. The `#[cfg(test)]` malloc-trim counters
moved with the split and the allowlist was not regenerated, leaving a stale
entry for the old path and an unrecorded one for the new.
Recorded rather than converted: `TEST_MALLOC_TRIM_CALLS` and
`TEST_MALLOC_TRIM_EXECUTED` are both `#[cfg(test)]` counters, so they are
cold by construction and `crate::perry_thread_local!` would buy nothing —
its point is keeping a hot address out of `_tlv_get_addr`, and these are
never on a shipping path.
`--update` also refreshes `_hot_declarations` 275 -> 278. That is a recount
of `perry_thread_local!` uses added since the file was last regenerated, not
a change of mine; the number moving up means more declarations are on the
hot macro, which is the direction the ratchet wants.
After: thread-local policy OK, 278 hot declarations, 125 raw blocks in 88
recorded cold files, capacity 768.
|
Merged immediately — this is my breakage and it was blocking every open PR. I split Why my own validation missed it, which is the part worth recording. I ran Your first hypothesis is the transferable bit: your #9258 touches only Two-line allowlist change, |
|
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 (1)
📝 WalkthroughWalkthroughThe thread-local cold allowlist increases the ChangesThread-local cold allowlist
Estimated code review effort: 1 (Trivial) | ~2 minutes ✨ 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 |
mainis currently red onself-test-checkers, which fails that check on every open PR. Two-line allowlist fix.Not any one PR's diff
Reproduced against a pristine
origin/mainworktree:I found it because it was failing on my own #9258, whose diff touches only
perry-codegen/src/stmt/loops.rsand therefore cannot affectperry-runtimethread-locals — "impossible for this diff" turned out to be the right first hypothesis.Both halves are one event, and it traces to my #9245
#9245 added 20 lines to
cycle.rs, pushing it past the 2000-line cap, so the merge splitcycle_malloc_trim.rsout of it. The#[cfg(test)]malloc-trim counters moved with the split and the allowlist was not regenerated — leaving a stale entry for the old path and an unrecorded one for the new. My change is the proximate cause, so this is mine to clean up.Recorded rather than converted
TEST_MALLOC_TRIM_CALLSandTEST_MALLOC_TRIM_EXECUTEDare both#[cfg(test)]-gated counters, so they are cold by construction.crate::perry_thread_local!exists to keep a hot address out of_tlv_get_addr; these are never on a shipping path, so converting them would add indirection for no benefit and misrepresent them as hot.One incidental change, flagged
--updatealso refreshes_hot_declarations275 → 278. That is a recount ofperry_thread_local!uses added since the file was last regenerated, not anything of mine. It moving up means more declarations sit on the hot macro, which is the direction the ratchet wants.After:
thread-local policy OK: 278 hot declarations, 125 raw blocks in 88 recorded cold files, capacity 768.Summary by CodeRabbit