Skip to content

gc: admit two provably-leaf helpers, and measure that it buys nothing - #7369

Merged
proggeramlug merged 3 commits into
fix/statepoint-report-count-from-mapfrom
perf/gc-leaf-register-global-root
Aug 4, 2026
Merged

gc: admit two provably-leaf helpers, and measure that it buys nothing#7369
proggeramlug merged 3 commits into
fix/statepoint-report-count-from-mapfrom
perf/gc-leaf-register-global-root

Conversation

@proggeramlug

Copy link
Copy Markdown
Contributor

Stacked on #7368 (needs its report fix to measure anything).

The audit

js_gc_register_global_root was the single most frequent non-leaf callee across the probe suite — 148 call sites — and it is provably GC-leaf. Its entire body:

pub extern "C" fn js_gc_register_global_root(ptr: i64) {
    if !root.is_null() {
        unsafe { runtime_write_barrier_root_heap_word(*root); }
    }
    GLOBAL_ROOTS.with(|roots| { roots.borrow_mut().push(root); });
}

The first call is exactly what js_write_barrier_root_heap_word — already CannotCollect — wraps in one line. It shades one header and calls push_mark_seed, which is a TLS Vec::push. No trace, no sweep, no trigger.

The Vec::push is the part worth pausing on, because CLAUDE.md lists a "malloc count threshold" as a GC trigger. It does not apply: that counter is MALLOC_STATE.objects.len(), a registry of Perry GC objects, and the #[global_allocator] is plain mimalloc/System with no GC hook. A raw Rust allocation cannot arm a trigger — the case the module doc already carves out ("may … allocate through the system allocator and still be safe").

js_typed_feedback_maybe_dump_trace joins its already-admitted family siblings: env read, JSON serialise, file write; empty body without diagnostics.

And it buys nothing — measured, same tree, A/B

probe safepoints roots total bytes __text
06_string_retention 105 → 100 27 → 27 0 −4 B
09_try_catch_roots 343 → 339 259 → 259 0 −4 B
11_collect_at_depth 120 → 117 36 → 36 0 −4 B

Root counts are identical. The 40 safepoints removed across the suite were all rootless, and a rootless safepoint costs essentially nothing.

Which is exactly what docs/engine-plan.md already told us:

Statepoints have no fixed cost. A function with nothing live across a safepoint pays nothing at all — the axis is not "statepoints are bigger", it is "roots are bigger".

I pulled the safepoint-count lever and confirmed it does not move the size axis. That is the useful output here: sequencing step 2's "reduce root density" has to attack live-root sets, not safepoint counts. I'd rather have that recorded with numbers than have the next person spend a week on the same lever.

Why land it at all

Three reasons, none of them "it's faster":

  1. The classification was wrong. js_gc_register_global_root is leaf and was marked Unknown. Accuracy in this table is load-bearing in the other direction too.
  2. The tests block the dangerous next step. allocating_helpers_are_not_cannot_collect pins js_nanbox_string out of the allowlist. At 120 call sites it's the obvious next candidate and reads as pure bit manipulation — but its null-pointer guard calls js_string_from_bytes to allocate an empty string rather than boxing null. I nearly admitted it before reading the body. Marking a collecting helper as leaf means the collector misses roots: silent heap corruption, the worst failure direction in this system.
  3. register_global_root_tracks_the_barrier_it_wraps ties the two classifications together, so a future demotion of the barrier can't leave its wrapper claiming to be leaf.

If you'd rather not carry a null-result change, the tests and the audit comments are the parts worth keeping — say so and I'll strip it to those.

Verification

Probe suite 11/11 byte-identical to the Node oracle under PERRY_RS4GC=1 PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1. cargo test -p perry-codegen --lib green.

proggeramlug and others added 3 commits August 4, 2026 12:19
)

`scripts/check_file_size.sh` exits 1 on main HEAD:
`crates/perry-codegen/src/expr/index_set.rs` is 2035 lines against a 2000
cap. It crossed in #7342.

That script runs inside the `lint` job, which is a REQUIRED context -- so
this is the second independent way `lint` was red on main today (the first
was rustfmt on linker.rs, #7361). A required check that is red on main blocks
nothing; it means every merge is a bypass.

The split follows the recipe in the script's own failure message: extract a
topical group into a sibling module. `lower_inline_dyn_typed_array_set` and
its `emit_inline_ta_int_store` helper are the guarded inline typed-array
store for a type-erased receiver -- one coherent unit, moved verbatim to
`index_set_typed_array.rs`. index_set.rs drops to 1749 lines, leaving real
headroom rather than landing one line under the cap.

Mechanical move: the two functions are byte-identical, only the imports they
need travelled with them and `lower_inline_dyn_typed_array_set` became
`pub(super)` so its one caller can still reach it.

cargo test -p perry-codegen --lib: 609 passed.

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF

Co-authored-by: Ralph Küpper <ralph@skelpo.com>
…tform matrix (#7367)

The plan still said statepoints were aarch64-only (#7321), that the matrix
"therefore runs on macos-14", that `statepoints-refuse-x86` pinned the refusal,
and it spelled the knob `PERRY_STATEPOINTS` four times. None of that is true
now, and this document is what the adoption decision gets made from.

What actually changed:

- x86-64 is unblocked. `_Unwind_GetGR(ctx, 7)` does segfault and cannot be
  fixed as stated -- libgcc tracks only the columns CFI restores and RSP is
  derived, not tracked. #7349 stopped asking for it and derives the SP-relative
  base from `_Unwind_GetCFA`, with a per-arch return-address adjustment (x86-64
  `call` pushes one, aarch64 `bl` does not). x86-64 Linux is a first-class arm.
- Windows works via RtlVirtualUnwind (#7355), the one walker with no Itanium
  unwinder beneath it.
- aarch64+ELF is now covered too (#7360) -- the only shape where LLVM spells
  32-bit stack-map fields `.word`.
- One mechanism, not two: PERRY_STATEPOINTS and the plain-map bridge are
  deleted, so the kill-policy line about "a mode that still exists" no longer
  applies to this pair.
- The gate proves something now. Until today the Unix arms reported 7 frames
  and ZERO locations -- they would have passed with a walker that visited
  nothing. #7359's deep-collect probe took them to 221 locations.
- watchOS/visionOS are not blocked by Perry: they build on stable without
  `dyn-eval`, and fail three crates away in psm's Mach-O guard.

So the remaining adoption gate is `llvm-inprocess` becoming a default cargo
feature, plus sequencing step 2 (root density) -- adopting today would regress
binary size on root-dense code.

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF

Co-authored-by: Ralph Küpper <ralph@skelpo.com>
js_gc_register_global_root was the most frequent non-leaf callee in the probe
suite (148 call sites) and is provably GC-leaf: its whole body is
runtime_write_barrier_root_heap_word -- which js_write_barrier_root_heap_word,
already CannotCollect, wraps in one line -- plus a TLS Vec::push. The "malloc
count threshold" trigger does not apply to that push: the counter is
MALLOC_STATE.objects.len(), a registry of Perry GC objects, and the
#[global_allocator] is plain mimalloc/System with no GC hook.
js_typed_feedback_maybe_dump_trace joins its already-admitted family siblings.

Measured A/B on the same tree, and the result is a null:

  probe                  safepoints    roots   total bytes   __text
  06_string_retention     105 -> 100   27=27             0     -4 B
  09_try_catch_roots      343 -> 339  259=259            0     -4 B
  11_collect_at_depth     120 -> 117   36=36             0     -4 B

Root counts are IDENTICAL. The 40 safepoints removed across the suite were all
rootless, and a rootless safepoint costs essentially nothing -- which is what
docs/engine-plan.md already says: "the axis is not 'statepoints are bigger', it
is 'roots are bigger'". Recording it as evidence: the safepoint-count lever is
not the binary-size lever, so sequencing step 2 must attack live-root SETS.

Two tests come with it. One pins the wrapper's classification to the barrier it
wraps. The other pins js_nanbox_string OUT of the allowlist: at 120 call sites
it is the obvious next candidate and reads as pure bit manipulation, but its
null guard calls js_string_from_bytes to allocate an empty string.

Probe suite 11/11 byte-identical under forced evacuation + verification.

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF
@coderabbitai

coderabbitai Bot commented Aug 4, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 0d895545-6921-4a72-926f-f7c9cc5d992e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@proggeramlug
proggeramlug merged commit 1d26ef6 into fix/statepoint-report-count-from-map Aug 4, 2026
9 of 15 checks passed
@proggeramlug
proggeramlug deleted the perf/gc-leaf-register-global-root branch August 4, 2026 11:17
proggeramlug added a commit that referenced this pull request Aug 4, 2026
…7368)

* fix(codegen): statepoint report counted zero safepoints since #7348

#7348 deleted the explicit bridge and with it the only callers of
note_statepoint and note_skipped -- they lived in the bridge, which counted
safepoints as it emitted them. The methods survived with no callers, so
statepoints, relocations, max_live_roots, skipped_non_safepoints,
live_roots_histogram and both by-callee maps went structurally zero in
production. A real compile printed "0 statepoints emitted" while its binary
carried 120.

Counting at IR-emission time cannot work any more, and that is the lesson:
Perry no longer decides which calls become safepoints -- RewriteStatepointsForGC
does, inside LLVM. The only honest source is the compact-map rewrite, which
already parses the assembly LLVM emitted and computed these exact numbers
before dropping them into log::debug!. The report reads from there now:

  120 safepoints across 6 function(s) in 1 module(s)
  36 live roots recorded, 0.30 per safepoint

An absent measurement no longer renders as a measured zero: gc_map.modules == 0
means "never reported", the text report says UNAVAILABLE rather than printing
zeros, and JSON carries gc_map separately from totals so a consumer can tell
them apart. schema_version -> 2.

The CI gate now asserts the counts, not just the label. --only-backend rs4gc
passed throughout the regression -- the label was right, the numbers were
fiction. It now also requires records > 0 and roots > 0; verified against a
synthetic report with the #7348 shape, where the label check still reports 9
functions green while the count checks exit 1.

Second round of dead counters here (#7362 removed four that never had a writer
at all). The new test documents why the first invariant missed this one:
every_rendered_counter_has_a_writer called the mutators itself, so "has a
writer" passed while "is written" was false.

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF

* gc: admit two provably-leaf helpers, and measure that it buys nothing (#7369)

* fix(lint): split index_set.rs, over the 2000-line cap since #7342 (#7366)

`scripts/check_file_size.sh` exits 1 on main HEAD:
`crates/perry-codegen/src/expr/index_set.rs` is 2035 lines against a 2000
cap. It crossed in #7342.

That script runs inside the `lint` job, which is a REQUIRED context -- so
this is the second independent way `lint` was red on main today (the first
was rustfmt on linker.rs, #7361). A required check that is red on main blocks
nothing; it means every merge is a bypass.

The split follows the recipe in the script's own failure message: extract a
topical group into a sibling module. `lower_inline_dyn_typed_array_set` and
its `emit_inline_ta_int_store` helper are the guarded inline typed-array
store for a type-erased receiver -- one coherent unit, moved verbatim to
`index_set_typed_array.rs`. index_set.rs drops to 1749 lines, leaving real
headroom rather than landing one line under the cap.

Mechanical move: the two functions are byte-identical, only the imports they
need travelled with them and `lower_inline_dyn_typed_array_set` became
`pub(super)` so its one caller can still reach it.

cargo test -p perry-codegen --lib: 609 passed.

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF

Co-authored-by: Ralph Küpper <ralph@skelpo.com>

* docs(plan): both statepoint adoption gates are closed; record the platform matrix (#7367)

The plan still said statepoints were aarch64-only (#7321), that the matrix
"therefore runs on macos-14", that `statepoints-refuse-x86` pinned the refusal,
and it spelled the knob `PERRY_STATEPOINTS` four times. None of that is true
now, and this document is what the adoption decision gets made from.

What actually changed:

- x86-64 is unblocked. `_Unwind_GetGR(ctx, 7)` does segfault and cannot be
  fixed as stated -- libgcc tracks only the columns CFI restores and RSP is
  derived, not tracked. #7349 stopped asking for it and derives the SP-relative
  base from `_Unwind_GetCFA`, with a per-arch return-address adjustment (x86-64
  `call` pushes one, aarch64 `bl` does not). x86-64 Linux is a first-class arm.
- Windows works via RtlVirtualUnwind (#7355), the one walker with no Itanium
  unwinder beneath it.
- aarch64+ELF is now covered too (#7360) -- the only shape where LLVM spells
  32-bit stack-map fields `.word`.
- One mechanism, not two: PERRY_STATEPOINTS and the plain-map bridge are
  deleted, so the kill-policy line about "a mode that still exists" no longer
  applies to this pair.
- The gate proves something now. Until today the Unix arms reported 7 frames
  and ZERO locations -- they would have passed with a walker that visited
  nothing. #7359's deep-collect probe took them to 221 locations.
- watchOS/visionOS are not blocked by Perry: they build on stable without
  `dyn-eval`, and fail three crates away in psm's Mach-O guard.

So the remaining adoption gate is `llvm-inprocess` becoming a default cargo
feature, plus sequencing step 2 (root density) -- adopting today would regress
binary size on root-dense code.

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF

Co-authored-by: Ralph Küpper <ralph@skelpo.com>

* gc: admit two provably-leaf helpers, and measure that it buys nothing

js_gc_register_global_root was the most frequent non-leaf callee in the probe
suite (148 call sites) and is provably GC-leaf: its whole body is
runtime_write_barrier_root_heap_word -- which js_write_barrier_root_heap_word,
already CannotCollect, wraps in one line -- plus a TLS Vec::push. The "malloc
count threshold" trigger does not apply to that push: the counter is
MALLOC_STATE.objects.len(), a registry of Perry GC objects, and the
#[global_allocator] is plain mimalloc/System with no GC hook.
js_typed_feedback_maybe_dump_trace joins its already-admitted family siblings.

Measured A/B on the same tree, and the result is a null:

  probe                  safepoints    roots   total bytes   __text
  06_string_retention     105 -> 100   27=27             0     -4 B
  09_try_catch_roots      343 -> 339  259=259            0     -4 B
  11_collect_at_depth     120 -> 117   36=36             0     -4 B

Root counts are IDENTICAL. The 40 safepoints removed across the suite were all
rootless, and a rootless safepoint costs essentially nothing -- which is what
docs/engine-plan.md already says: "the axis is not 'statepoints are bigger', it
is 'roots are bigger'". Recording it as evidence: the safepoint-count lever is
not the binary-size lever, so sequencing step 2 must attack live-root SETS.

Two tests come with it. One pins the wrapper's classification to the barrier it
wraps. The other pins js_nanbox_string OUT of the allowlist: at 120 call sites
it is the obvious next candidate and reads as pure bit manipulation, but its
null guard calls js_string_from_bytes to allocate an empty string.

Probe suite 11/11 byte-identical under forced evacuation + verification.

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF

---------

Co-authored-by: Ralph Küpper <ralph@skelpo.com>

* fix(ci): report assertion pinned to a probe Windows cannot compile

Three review fixes on #7368.

The report assertion ran on 09_try_catch_roots, which contains four `try`
blocks. RS4GC cannot rewrite WinEH funclet pads, so linker.rs's
rs4gc_funclet_refusal rejects that probe on windows-msvc -- the probe loop
above tolerates it by grepping the compile log for "funclet", but this step
did not. A gate pinned to a probe that cannot compile on one arm fails for a
reason unrelated to its subject. The portable assertion now uses
11_collect_at_depth (no `try`, compiles on all four arms); 09_try_catch_roots
keeps its own non-Windows step so the try-specific coverage that justified
deleting the bridge is not lost.

The gc_map doc claimed records/roots would be ABSENT when unmeasured. They
are plain u64 fields on a plain derive and always serialise; `modules` is the
sentinel. Fixed to describe what the code actually does -- the same class of
comment-vs-code drift this PR exists to clean up.

The "map never reported" guard fired for any --require-*/--print, including
fields that live in `totals` and are counted at IR-emission time whether or
not the rewrite ran. Now scoped to map-backed fields: --require-positive
textual_calls is answered from its measured value (verified exit 0) while
--require-positive records still fails on an unreported map (exit 1).

Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF

---------

Co-authored-by: Ralph Küpper <ralph@skelpo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant