Make a rare garbage-collector bug reproducible on demand (PERRY_GC_SCHEDULE_SEED)

[jdalton]

Making a rare garbage-collector bug show up on demand

This adds a way to control when the garbage collector runs. A bug that normally shows up in about 1 run out of 60 can now be reproduced in about a second — and reproduced again the same way tomorrow, because you get a number back that replays the exact same run.

The problem

Perry has a garbage collector: it periodically finds memory the program is no longer using and reclaims it, sometimes moving still-live objects to new addresses while it does so. For that to be safe, the compiler has to tell the collector about every value the program is still holding. When it misses one, the collector either frees that value or moves it and leaves the program pointing at the old address. The program then keeps running with a bad pointer and crashes later somewhere unrelated, usually as TypeError: value is not a function.

Here is the awkward part. Whether that bug shows up at all depends entirely on whether a collection happens to land inside the small window where the value is unprotected. That is a property of the collector's timing, not of the bug. Normally collections happen tens of megabytes of allocation apart, so most runs sail straight past the window and finish fine.

That is why these bugs feel random, and why the usual response — run it again a bunch of times — does not actually work.

Why "just run it 100 times" tells you almost nothing

Say you have a fix and you want to confirm it. You run the program 120 times, see no failures, and call it fixed.

Statistically that is much weaker than it feels. With zero failures in N runs, the standard 95% confidence bound says the real failure rate could still be as high as roughly 3/N. So 120 clean runs only prove the failure rate is below about 2.5% — and the bug we were chasing has a rate of about 1.7%. The evidence is entirely consistent with the bug still being there, untouched.

To get real confidence by repetition alone you would need on the order of a thousand runs, every time you wanted to check anything.

The deeper issue is that repetition is not even exploring. Running one binary 60 times runs the same collection timing 60 times. You are not sampling 60 different scenarios; you are sampling one scenario 60 times.

What this adds

Set PERRY_GC_SCHEDULE_SEED to any number, and that number decides when collections happen. The decision is pseudo-random, so different seeds produce genuinely different collection timings and actually explore the problem space. But it is computed purely from the seed, so the same seed always produces the same timing — which means a seed that triggers a crash is the bug report. Anyone can replay it.

A second variable, PERRY_GC_SCHEDULE_RATE, controls how often collections happen, from "never" up to "at every opportunity". It defaults to 5%.

There is also scripts/gc_schedule_fuzz.sh, which tries a range of seeds and prints a ready-to-paste command for each one that fails.

Does it actually work?

Yes. The test subject is Socket Firewall's sfw-registry --help, which had been failing roughly 1 run in 60 — the kind of failure that had already cost days of investigation because nobody could summon it on demand.

Same binary, same machine (macOS arm64), four runs at a time:

what was run	result	time
No seed set — the control	0 failures out of 16	55 seconds each, all finished
Seeds 1 through 12, rate 5%	6 of 12 failed, each in under 2 seconds	the other 6 were cut off at 120 seconds

The failures fell into two consistent groups:

seeds 1, 7, 12 → TypeError: value is not a function
                   at node_modules/zod/src/v4/classic/schemas.ts:1318
seeds 8, 9, 11 → TypeError: Cannot convert undefined or null to object
                   at node_modules/node-machine-id/dist/index.js:1

The first group is exactly the failure the investigation had been chasing. Seed 1 was then re-run five more times and failed all five, at the identical source location, in under a second each time:

PERRY_FORCE_WELL_KNOWN=iovalkey PERRY_GC_MOVING_LOOP_POLLS=1 \
PERRY_GC_SCHEDULE_SEED=1 PERRY_GC_SCHEDULE_RATE=0.05 \
  ./binaries/sfw-registry --help

So the thing that used to take an hour of re-running now takes a second, and comes with a copy-pasteable reproduction.

What it costs, and why half the sweep shows no result

Collecting more often is slower — roughly 5 to 10 times slower on this workload. That is why six of the twelve seeds above are listed as "cut off" rather than "passed": they had not finished within the 120-second limit, so we genuinely do not know whether they would have failed.

In practice this barely matters, because the seeds that find something fail in 1 to 2 seconds. The wall-clock time of a sweep is dominated entirely by the seeds that are not going to tell you anything. Turn the rate down or the timeout up depending on which you would rather buy.

How the timing decision actually works

Every so often a running Perry program reaches a point where it is safe to collect — the compiler guarantees that at these points it has told the collector about everything. Each thread counts these points: 1, 2, 3, and so on.

At each one, the program computes a hash of (your seed, this counter value) and collects if the result falls below a threshold derived from the rate you asked for. That is the whole decision. It reads no clock, no memory address, and no thread identity, which is precisely what makes it replayable.

A collection triggered this way also moves surviving objects rather than just sweeping. That matters: the entire class of bug being hunted is "the program kept a pointer to something that moved", so a mode that never moved anything would look busy and find nothing.

What it deliberately does not do

This only adds collections; it never removes or delays one that would have happened anyway. Turning it on can make a program collect more, never less.

It does not force a collection at moments the collector considers unsafe. If the program is in the middle of an allocation, inside a foreign-function call, or otherwise in a state where collecting would be wrong, the safepoint is skipped — and deliberately does not consume a counter tick, so the sequence stays aligned with points that could actually have collected.

It cannot create collection opportunities the compiler never emitted. If a program's hot loop has no safepoint in it, no seed can invent one, and the run will only collect at event-loop boundaries. The exit summary prints how many were reached, so you can check rather than assume.

Finally, a value that is not a valid number reads as off, not as seed 0. A typo must not silently give you a mode you did not ask for.

How reproducible this really is (the honest version)

For a single-threaded program, a seed replays exactly: same seed, same binary, same inputs, same collection timing, every time.

For a program using perry/thread, each thread has its own counter, so each thread's timing is deterministic given that thread's own sequence of safepoints. What nobody can promise is that the operating system schedules those threads identically twice. So a multi-threaded reproduction is only as reproducible as its threading.

The alternative — one shared counter across all threads — would be strictly worse, because then even a single thread's timing would depend on how the others interleaved. Per-thread is the version that keeps the guarantee meaningful where it can be kept.

You never lose the seed, even if the program dies badly

A fuzzer that finds a bug and loses the reproduction is worthless, so the seed is printed in four places: at startup, at exit, on a panic, and from a crash handler covering segfaults and aborts.

The crash handler is careful in two ways. It chains to whatever handler was already installed rather than replacing it, and the from-space memory-protection tooling re-installs it after setting up its own. That means when you combine this with PERRY_GC_PROTECT_FROMSPACE=1 — which is the natural pairing, since it turns a stale pointer into an immediate fault at the exact instruction — you get both the seed and the precise crash location, instead of one clobbering the other.

The exit summary also reports how much the run actually did: how many safepoints were seen, how many collections were forced, how many objects moved. A clean run that did nothing looks very different from a clean run that did a lot, and now you can tell them apart.

Proving it is genuinely off by default

A debugging feature that quietly changes behaviour when it is switched off is worse than no feature. So this was measured rather than assumed.

With no seed set, the collector's diagnostic traces are byte-for-byte identical to the commit this branch is based on, across five different configurations on two test programs — including a 367-line trace in the normal configuration and a 6151-line trace with maximum collection pressure and memory protection both enabled.

Tests

gc/tests/schedule.rs has 12 tests covering both settings in both directions: that bad values are rejected, that the rate endpoints mean exactly "never" and "always", that the same seed picks the same 100,000 decisions twice running, that neighbouring seeds pick genuinely different ones (otherwise a sweep would be re-running one experiment under different names), that the measured collection rate matches the requested one at four different rates, and that a real safepoint collects, declines, or is skipped in the right circumstances.

scripts/gc_instrument_smoke.sh gains three end-to-end checks that gate the three claims this feature makes: that a middle rate really is in the middle (measured on the test program: 0 collections with no seed, 989 at 25%, 1230 at 100% — so it is a genuine range, not a second name for an endpoint), and that the same seed run twice produces exactly the same number.

cargo test -p perry-runtime on this branch: 1670 passed, 0 failed, run single-threaded, twice in a row.

Two notes on scope

This no longer deletes anything. An earlier version of this pull request also removed the older stress-testing setting, PERRY_GC_ZEAL. That turned out to deserve its own discussion, so it now has one in #7741. This branch adds the new capability alongside the existing one and changes nothing about how the collector behaves by default.

The one real failure this branch owned is fixed separately. Running the conformance suite against this branch turned up a segmentation fault in test_gap_buffer_own_props. It is fixed in #7747, which targets main rather than this branch, because the bug predates this work: reading a method off a Buffer without calling it produced a callable that remembered the method's name as a pointer into memory that had already been freed. Its sibling test test_gap_buffer_own_prop_shadow_intrinsic_6405 already crashes on main today for the same reason.

That is also a good illustration of why this pull request exists. Whether reading freed memory actually goes wrong depends on whether anything has reused it yet, so collecting more often here made an existing bug visible without this branch touching a single line of Buffer code. Once #7747 lands I will rebase this branch onto it and re-run the conformance suite.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

This change replaces GC zeal with deterministic, rate-controlled seeded scheduling. It integrates scheduled safepoints with collection and evacuation policy, adds exit and signal diagnostics, provides tests and fuzzing tools, and updates GC reproduction documentation.

Changes

Seeded GC schedule fuzzing

Layer / File(s)	Summary
Schedule configuration and selection crates/perry-runtime/src/gc/schedule.rs, crates/perry-runtime/src/gc/mod.rs, crates/perry-runtime/src/gc/tests/*	Adds seed and rate parsing, deterministic per-thread safepoint selection, cached configuration, counters, metric accessors, and test overrides.
Safepoint collection and evacuation integration crates/perry-runtime/src/gc/policy.rs, crates/perry-runtime/src/gc/mod.rs, crates/perry-runtime/src/gc/tests/*	Connects selected safepoints to moving minor collections, forced evacuation, collection attribution, entry guards, and exit summaries.
Failure and signal diagnostics crates/perry-runtime/src/gc/schedule.rs, crates/perry-runtime/src/arena/quarantine.rs, crates/perry-runtime/src/native_handle.rs	Adds startup, exit, panic, and fatal-signal reporting while preserving quarantine signal-handler chaining.
Schedule tests and fuzzing workflows crates/perry-runtime/src/gc/tests/*, scripts/gc_instrument_smoke.sh, scripts/gc_schedule_fuzz.sh, run_parity_tests.sh	Tests parsing, determinism, safepoint behavior, evacuation policy, signal output handling, smoke arms, and seeded sweep execution.
Configuration and reproduction documentation CLAUDE.md, docs/src/internals/*, changelog.d/*, test-files/*, test-parity/*, .github/workflows/test.yml	Replaces zeal-based instructions with seeded schedule controls and documents reproduction, quarantine depth, determinism, reporting, and workflow validation.

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Runtime
  participant Safepoint
  participant Schedule
  participant Collector
  participant Reporter
  Runtime->>Schedule: resolve seed and rate
  Safepoint->>Schedule: advance handled safepoint
  Schedule-->>Safepoint: return collection selection
  Safepoint->>Collector: perform scheduled moving minor
  Collector->>Reporter: record forced collection
  Reporter-->>Runtime: report counters on exit or failure

Loading

Possibly related PRs

• PerryTS/perry#7196: Evolves the earlier GC zeal instrumentation in the same runtime and tooling areas.
• PerryTS/perry#7015: Also changes GC safepoint behavior in crates/perry-runtime/src/gc/policy.rs.
• PerryTS/perry#7314: Also changes GC safepoint and collection behavior in gc/policy.rs and gc/mod.rs.

Suggested reviewers: proggeramlug

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main change: deterministic reproduction of rare garbage-collector bugs using PERRY_GC_SCHEDULE_SEED.
Description check	✅ Passed	The description thoroughly covers the feature, implementation details, testing, results, limitations, and related pull requests.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 10

🧹 Nitpick comments (3)

crates/perry-runtime/src/gc/schedule.rs (1)

244-252: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Align the "startup banner" claim with the actual announcement point.

The module documentation at Lines 331-334 describes layer 1 as "a startup banner, so the seed is in the log even if the failure mode is a hang or a _exit that runs no handler at all". resolved() runs the announcement lazily, at the first call site. For a mode-ON run, that is the first safepoint or the first gc_force_evacuate_enabled() query. A hang or _exit before that point prints nothing, and no panic hook or signal handler is installed either.

Consider resolving the configuration eagerly from GC initialization, or narrow the documentation claim to "the first safepoint" so an operator does not read a missing banner as "the seed was not set".

🤖 Prompt for 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.

In `@crates/perry-runtime/src/gc/schedule.rs` around lines 244 - 252, The
startup-banner documentation does not match the lazy announcement in resolved().
Either eagerly resolve the configuration during GC initialization so
publish_seed and announce run before early hangs or _exit paths, or narrow the
layer-1 documentation to state that the banner appears at the first safepoint or
gc_force_evacuate_enabled() query; preserve the existing seed publication
behavior.

crates/perry-runtime/src/gc/tests/schedule.rs (1)

276-283: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Release the GC root lock with a guard so a panic cannot leak the depth.

enter_gc_root_lock() and exit_gc_root_lock() are paired manually. If gc_safepoint_moving_minor() panics, exit_gc_root_lock() never runs, the root-lock depth stays non-zero for this thread, and every later collection on that thread is blocked. That converts one failure into a cascade of confusing failures in the same test binary.

♻️ Proposed fix using a scope guard

     let safepoints_before = gc_schedule_safepoints();
     {
         let _schedule = ScheduleGuard::set(7, rate_threshold(1.0));
         reset_thread_counter_for_test();
-        super::super::roots::enter_gc_root_lock();
-        gc_safepoint_moving_minor();
-        super::super::roots::exit_gc_root_lock();
+        struct RootLock;
+        impl RootLock {
+            fn enter() -> Self {
+                super::super::roots::enter_gc_root_lock();
+                Self
+            }
+        }
+        impl Drop for RootLock {
+            fn drop(&mut self) {
+                super::super::roots::exit_gc_root_lock();
+            }
+        }
+        let _lock = RootLock::enter();
+        gc_safepoint_moving_minor();
     }

If the test support module already exposes a root-lock guard type, use it instead of the local shim.

🤖 Prompt for 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.

In `@crates/perry-runtime/src/gc/tests/schedule.rs` around lines 276 - 283, Update
the test block around gc_safepoint_moving_minor to use the existing GC root-lock
scope guard, if exposed by the test support module, instead of manually pairing
enter_gc_root_lock and exit_gc_root_lock. Ensure the guard releases the lock
during unwinding as well as normal completion, and remove the corresponding
explicit exit call.

docs/src/internals/gc-rooting-invariant.md (1)

271-279: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Keep the gc_schedule_fuzz.sh argument syntax deterministic.

The script accepts <binary> [seed-count], but CLAUDE.md still says [seeds]. Update that line so the two docs use the actual positional argument semantics.

🤖 Prompt for 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.

In `@docs/src/internals/gc-rooting-invariant.md` around lines 271 - 279, Update
the gc_schedule_fuzz.sh usage text in CLAUDE.md to describe the second
positional argument as seed-count, matching the script’s actual <binary>
[seed-count] semantics. Also review the usage reference in
docs/src/internals/gc-rooting-invariant.md and
changelog.d/7307-seeded-gc-schedule-fuzzing.md at the specified ranges; update
any remaining [seeds] wording there to [seed-count], with no other changes.

🤖 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 `@CLAUDE.md`:
- Around line 145-146: Add a required CI workflow arm for the seeded GC schedule
OFF state, using a compiled program to test both an unset PERRY_GC_SCHEDULE_SEED
and PERRY_GC_SCHEDULE_RATE set without a seed. Verify both remain schedule-inert
while pressure-driven collections still occur, reusing the existing
scripts/gc_schedule_fuzz.sh or schedule test infrastructure where appropriate.

In `@crates/perry-runtime/src/gc/mod.rs`:
- Around line 778-784: The exit summary is emitted during per-thread teardown,
so SUMMARY_EMITTED can capture counts before other threads finish. Update the
report_exit_summary call in the exit path to emit only after all worker threads
have completed teardown—prefer the existing main-thread or final-thread
coordination mechanism—and preserve once-only reporting with complete safepoints
and scheduled_collections totals.

In `@crates/perry-runtime/src/gc/schedule.rs`:
- Around line 240-243: Add a required CI workflow arm that runs the GC schedule
tests or relevant test suite with PERRY_GC_SCHEDULE_SEED and
PERRY_GC_SCHEDULE_RATE unset, verifying their default/OFF behavior alongside
existing CI coverage. Anchor the change to the workflow job invoking the tests
and preserve the current configured-knob coverage.
- Around line 584-608: In the signal-handler teardown around the previous
handler lookup, restore SIG_DFL before entering the previous > 1 chaining path,
so the default disposition is installed before invoking the chained handler.
Keep the existing chained-handler call and early return, but remove the
later-only restoration structure so schedule_fault_handler cannot loop when the
chained handler returns.
- Around line 493-502: Update the previous-handler storage in
reinstall_signal_reporter_after to check old.sa_flags for libc::SA_SIGINFO
before saving old.sa_sigaction. Store 0 for handlers without SA_SIGINFO, while
preserving the existing self-chain prevention and storing the handler value only
when the flag is present.

In `@docs/src/internals/gc-rooting-invariant.md`:
- Around line 281-285: Update the paragraph beginning “A rate is not a
substitute for a schedule” to qualify the ~3/N confidence bound as applying only
to independent trials. State that repeated runs with a fixed seed or
deterministic schedule are correlated, so 0/N failures provide no statistical
bound, while preserving the guidance to vary collection timing.

In `@docs/src/internals/memory-model.md`:
- Around line 138-139: Update the PERRY_GC_SCHEDULE_SEED and
PERRY_GC_SCHEDULE_RATE documentation to describe the configured rate as
additional schedule density for minor collections only, applied when
gc_budgeted_due_trigger() reports no pressure-driven collection is due. Clarify
that pressure-driven collections still occur independently, so the rate is not
the total fraction of safepoints that collect, and replace the current “iff”
wording with this behavior.

In `@scripts/gc_instrument_smoke.sh`:
- Around line 119-129: Replace the `run_arm ... | tail -1` command substitutions
for `sched_retired`, `sched_repeat`, and `sched_other` with output capture that
does not use a pipeline, then explicitly check each `run_arm` exit status and
abort on failure before comparing results. Apply the same status-preserving
change to the other arms in this script that use the pipeline pattern, while
retaining extraction of the final output line.
- Around line 150-164: The strict schedule-density checks in the smoke fixture
can fail on low safepoint counts without demonstrating a broken rate knob.
Update the fixture to generate enough handled GC safepoints for distinct
retirement counts, or revise both failure paths around sched_retired,
nozeal_retired, and zeal_retired to report all three counts before exiting.

In `@scripts/gc_schedule_fuzz.sh`:
- Around line 53-59: Validate SEED_COUNT immediately after argument parsing as a
positive integer, rejecting zero and non-numeric values with an error and
nonzero exit. In the final summary around FAILED_SEEDS and the PASS output,
track executed runs via passed plus failed seeds and exit nonzero with a failure
message when that total is zero; only report PASS after at least one seed ran.

---

Nitpick comments:
In `@crates/perry-runtime/src/gc/schedule.rs`:
- Around line 244-252: The startup-banner documentation does not match the lazy
announcement in resolved(). Either eagerly resolve the configuration during GC
initialization so publish_seed and announce run before early hangs or _exit
paths, or narrow the layer-1 documentation to state that the banner appears at
the first safepoint or gc_force_evacuate_enabled() query; preserve the existing
seed publication behavior.

In `@crates/perry-runtime/src/gc/tests/schedule.rs`:
- Around line 276-283: Update the test block around gc_safepoint_moving_minor to
use the existing GC root-lock scope guard, if exposed by the test support
module, instead of manually pairing enter_gc_root_lock and exit_gc_root_lock.
Ensure the guard releases the lock during unwinding as well as normal
completion, and remove the corresponding explicit exit call.

In `@docs/src/internals/gc-rooting-invariant.md`:
- Around line 271-279: Update the gc_schedule_fuzz.sh usage text in CLAUDE.md to
describe the second positional argument as seed-count, matching the script’s
actual <binary> [seed-count] semantics. Also review the usage reference in
docs/src/internals/gc-rooting-invariant.md and
changelog.d/7307-seeded-gc-schedule-fuzzing.md at the specified ranges; update
any remaining [seeds] wording there to [seed-count], with no other changes.

🪄 Autofix (Beta)

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: 77947a25-2bab-41b8-b287-31da05030b5f

📥 Commits

Reviewing files that changed from the base of the PR and between 6bedb25 and 2467132.

📒 Files selected for processing (12)

• CLAUDE.md
• changelog.d/7307-seeded-gc-schedule-fuzzing.md
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/policy.rs
• crates/perry-runtime/src/gc/schedule.rs
• crates/perry-runtime/src/gc/tests/mod.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• docs/src/internals/gc-rooting-invariant.md
• docs/src/internals/memory-model.md
• scripts/gc_instrument_smoke.sh
• scripts/gc_schedule_fuzz.sh

[coderabbitai]

Actionable comments posted: 3

🤖 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 `@CLAUDE.md`:
- Line 145: Update the PERRY_GC_SCHEDULE_SEED documentation to name Perry’s
process-exit teardown funnel as the source of seed reporting for _exit-based
exits, while describing atexit only as an additional reporting path. Preserve
the existing panic and signal-reporting paths and all other seed behavior.
- Around line 145-148: Condense the PERRY_GC_SCHEDULE_SEED and
PERRY_GC_SCHEDULE_RATE entries in CLAUDE.md to their concise runtime contract,
removing implementation rationale, reproduction guidance, and historical
context. Move that detailed narrative, including measurement guidance, to
changelog.d/7317-seeded-gc-schedule-fuzzing.md while preserving the documented
behavior and configuration semantics.
- Line 148: Update the documented invocation of scripts/gc_schedule_fuzz.sh to
use the optional argument name [seed-count] instead of [seeds], while preserving
the existing binary argument and surrounding guidance.

🪄 Autofix (Beta)

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: 91c7b636-1ffb-4ec0-ba19-591b2f2b1559

📥 Commits

Reviewing files that changed from the base of the PR and between 2467132 and 5d8ce73.

📒 Files selected for processing (12)

• CLAUDE.md
• changelog.d/7317-seeded-gc-schedule-fuzzing.md
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/policy.rs
• crates/perry-runtime/src/gc/schedule.rs
• crates/perry-runtime/src/gc/tests/mod.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• docs/src/internals/gc-rooting-invariant.md
• docs/src/internals/memory-model.md
• scripts/gc_instrument_smoke.sh
• scripts/gc_schedule_fuzz.sh

🚧 Files skipped from review as they are similar to previous changes (10)

• docs/src/internals/gc-rooting-invariant.md
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/tests/mod.rs
• scripts/gc_instrument_smoke.sh
• crates/perry-runtime/src/gc/mod.rs
• docs/src/internals/memory-model.md
• crates/perry-runtime/src/gc/policy.rs
• scripts/gc_schedule_fuzz.sh
• crates/perry-runtime/src/gc/tests/schedule.rs
• crates/perry-runtime/src/gc/schedule.rs

[proggeramlug]

The premise is right and it is the most useful framing anyone has put on this class:

Whether a #7154-class bug is caught is a property of the GC schedule, not of the bug — re-running one binary sixty times re-runs one schedule sixty times and explores almost nothing.

That explains something we have been misreading. #7280's acceptance arms read 6, 8, 9 out of 30 across three runs of the same parent — we have been treating that as noise to work around, when it is really one schedule being sampled repeatedly. A seeded sweep is the right instrument, and it arrives at exactly the moment it is most needed: the owner has chosen to make statepoints the default and delete the shadow stack, and the soak deciding that is running now.

Not merging yet, for two reasons:

1. Two new knobs with no CI arm. PERRY_GC_SCHEDULE_SEED and PERRY_GC_SCHEDULE_RATE appear in no workflow. CLAUDE.md's kill-policy is binding — an arm exercising the OFF state each, or deletion after one release of soak, with at most one diagnostic-only knob labelled untested. There is an agent clearing exactly this debt for Native-frame GC roots via LLVM statepoints, opt-in (#7173, #7174) #7314's five knobs right now; adding two more uncovered ones while that runs would undo it. This repo has paid for unexercised modes repeatedly — PERRY_GC_FORCE_EVACUATE was inert for every gc()-driven test for months (gc: no reachable configuration exercises an evacuating minor with unpinned runtime locals — the #6655/#6935 bug class is untestable #6942/GC testing: PERRY_GC_FORCE_EVACUATE is inert for gc()-driven tests (full mark-sweep + forced conservative scan) — stress claims may be unsupported #6946).

2. Six unaddressed Critical/Major review comments, including two on gc/schedule.rs about sigaction/SA_SIGINFO flags. Signal-handler code in the collector is not somewhere to merge on trust, and I have merged past Major comments three times today — twice harmlessly, once not (fix(gc): reload BOTH stale operands when one instruction has two (#7311 follow-up) #7316 had to fix a dropped operand rewrite that made a headline 137→0 count mean less than it appeared to).

What would make this land fast: the CI arm, and the two schedule.rs signal comments answered. The CLAUDE.md comment is the same kill-policy point as (1).

I have pointed the soak agent at this branch so it can use the sweep locally for schedule exploration without waiting on the merge — if it finds a failing seed on the statepoint arm, that is exactly the evidence the flip decision needs, and it would be a strong argument for landing this.

[coderabbitai]

Actionable comments posted: 2

🤖 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 `@changelog.d/7317-seeded-gc-schedule-fuzzing.md`:
- Around line 45-48: Update the 0/16 statistical statement in the changelog to
identify the confidence level and interval method used for the ~19% upper bound,
specifically describing it as a 95% Wilson upper bound.

In `@CLAUDE.md`:
- Around line 145-146: Update the CI workflow coverage for the GC scheduling
configuration to add required arms for an unset PERRY_GC_SCHEDULE_SEED and for
PERRY_GC_SCHEDULE_RATE configured without a seed. In each arm, verify
pressure-driven collections remain active while schedule-triggered collections
stay disabled, matching the documented OFF-state behavior.

🪄 Autofix (Beta)

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: 3b65e0cf-c3cf-401f-8906-3df203dedc2b

📥 Commits

Reviewing files that changed from the base of the PR and between 5d8ce73 and 9c43d77.

📒 Files selected for processing (12)

• CLAUDE.md
• changelog.d/7317-seeded-gc-schedule-fuzzing.md
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/policy.rs
• crates/perry-runtime/src/gc/schedule.rs
• crates/perry-runtime/src/gc/tests/mod.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• docs/src/internals/gc-rooting-invariant.md
• docs/src/internals/memory-model.md
• scripts/gc_instrument_smoke.sh
• scripts/gc_schedule_fuzz.sh

🚧 Files skipped from review as they are similar to previous changes (10)

• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/policy.rs
• docs/src/internals/gc-rooting-invariant.md
• scripts/gc_schedule_fuzz.sh
• docs/src/internals/memory-model.md
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• crates/perry-runtime/src/gc/schedule.rs
• crates/perry-runtime/src/gc/tests/mod.rs
• scripts/gc_instrument_smoke.sh

[jdalton]

Follow-up in ca397efb9: I went back over the three findings I had initially pushed back on, and on a closer read two of them were real bugs and the third was worth doing anyway. Credit where due.

The signal-chain infinite loop was real, and my first pass was wrong to call it a false positive. Returning from a synchronous fault handler re-runs the faulting instruction, so if the chained quarantine handler also returned without resolving the fault, the disposition still pointed at us and we re-entered forever. The fix restores SIG_DFL for the signal before chaining, so the re-fault always dies at the real site no matter what the chained handler does.

The | tail -1 masking was also real. The exit 1 inside run_arm only left the command-substitution subshell, and the pipeline reported the status of tail, so a crashed arm was silently swallowed. The human-readable line now goes to stderr, stdout carries only the count, and every arm runs as "$(run_arm …)" || exit 1, so a crash propagates.

The exit-summary gating I took as an improvement even though the original behavior was defensible. It now gates on a pure read, native_handle::is_main_thread_or_unrecorded(), which emits on the main thread or whenever no main thread was ever recorded — so a worker tearing down first no longer wins the once-only swap with non-final counts, and the summary still cannot be silently dropped.

Where the OFF-state CI arm stands after this

The required cargo-test coverage is complete as-is: the_schedule_collects_at_a_safepoint_with_no_pressure_due asserts the live subject (forced collections grew with a seed set) and the OFF arm (an idle safepoint neither collects nor ticks), and the integrated smoke arm now propagates crashes instead of masking them. The one remaining piece is promoting that smoke arm into the branch-protection required contexts, which is a settings change on the protected repo that a fork PR has no way to make — flagged for a maintainer after one green run.

[coderabbitai]

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/native_handle.rs`:
- Around line 62-73: Update is_main_thread_or_unrecorded and its exit-summary
callers so an unrecorded MAIN_THREAD_ID does not allow a worker thread to claim
SUMMARY_EMITTED. Prefer ensuring js_native_handle_mark_main_thread() runs during
startup before workers begin, or make the teardown diagnostic skip callers while
MAIN_THREAD_ID remains 0; preserve acceptance only for the registered main
thread.

🪄 Autofix (Beta)

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: 5fe7a9c1-d4d9-4981-bddc-14cde04fae59

📥 Commits

Reviewing files that changed from the base of the PR and between 9c43d77 and ca397ef.

📒 Files selected for processing (13)

• CLAUDE.md
• changelog.d/7317-seeded-gc-schedule-fuzzing.md
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/policy.rs
• crates/perry-runtime/src/gc/schedule.rs
• crates/perry-runtime/src/gc/tests/mod.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• crates/perry-runtime/src/native_handle.rs
• docs/src/internals/gc-rooting-invariant.md
• docs/src/internals/memory-model.md
• scripts/gc_instrument_smoke.sh
• scripts/gc_schedule_fuzz.sh

🚧 Files skipped from review as they are similar to previous changes (10)

• docs/src/internals/gc-rooting-invariant.md
• crates/perry-runtime/src/gc/tests/mod.rs
• crates/perry-runtime/src/gc/policy.rs
• scripts/gc_instrument_smoke.sh
• docs/src/internals/memory-model.md
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• scripts/gc_schedule_fuzz.sh
• crates/perry-runtime/src/gc/schedule.rs

[jdalton]

@coderabbitai resolve

[coderabbitai]

Actionable comments posted: 7

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

changelog.d/7317-seeded-gc-schedule-fuzzing.md (1)

142-144: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Reconcile the reported runtime test count before publishing this result.

This fragment reports 1670 passed, while the PR objectives report 1687 runtime library tests passing for the latest commit. Confirm whether the commands or feature sets differ. Update this fragment to the exact run that supports the current PR.

🤖 Prompt for 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.

In `@changelog.d/7317-seeded-gc-schedule-fuzzing.md` around lines 142 - 144,
Reconcile the runtime test-count claims in the changelog entry: verify the
command and feature set used for the reported run against the latest PR result,
then update the embedded test counts and run details to exactly match the
current supporting execution. Remove or revise the stale comparison if it no
longer reflects that run.

docs/statepoint-gc-experiment.md (1)

933-942: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Update the stale platform limitation.

The bullet says scanning is “macOS/Mach-O-only,” but the same document reports x86-64 and AArch64 Linux verification at Lines 589-613. State the current platform support, or label this bullet as an earlier prototype limitation.

🤖 Prompt for 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.

In `@docs/statepoint-gc-experiment.md` around lines 933 - 942, The bullet point
stating "scanning is macOS/Mach-O-only" contradicts the platform verification
reported elsewhere in the document (x86-64 and AArch64 Linux support at lines
589-613). Update this bullet to accurately reflect the current platform support
including Linux platforms, or if this limitation applies only to an earlier
prototype version, explicitly label it as such to clarify the scope and timeline
of the constraint.

♻️ Duplicate comments (1)

docs/src/internals/gc-rooting-invariant.md (1)

281-285: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Qualify the ~3/N bound.

The paragraph says fixed-seed repetitions replay one schedule, but then applies the binomial ~3/N bound to those repetitions. State that fixed-seed repetitions provide no statistical bound. Limit ~3/N to independent schedule or workload trials.

🤖 Prompt for 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.

In `@docs/src/internals/gc-rooting-invariant.md` around lines 281 - 285, The
paragraph currently applies the ~3/N statistical bound to fixed-seed repetitions
without clarifying that this bound is invalid for that scenario. Revise the text
to explicitly state that re-running the same binary with fixed seeds provides no
statistical bound on the true bug rate. Then limit the ~3/N bound statement to
apply only when runs use independent schedules or workloads, making clear the
distinction between replayed runs (which don't accumulate statistical evidence)
and varied runs (which do).

🤖 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 @.github/workflows/test.yml:
- Around line 1085-1091: Update the repository branch-protection required status
checks to include the existing GATING `gc-stress` context, ensuring failures
from the GC smoke-test workflow block merges. Do not alter the workflow test
logic.

In `@changelog.d/7219-registry-gc-unrooted-caches.md`:
- Around line 125-126: The `PERRY_GC_SCHEDULE_RATE` parameter is only effective
when `PERRY_GC_SCHEDULE_SEED` is set, so all documented test environments using
rate-1 scheduling must explicitly include the seed value. In
changelog.d/7219-registry-gc-unrooted-caches.md lines 125-126, add
`PERRY_GC_SCHEDULE_SEED=1` to both closure-call table rows. In
changelog.d/7227-regexp-receiver-rooting-and-alloc-re-audit.md lines 141-142,
add the seed to both regexp-receiver table rows. In
changelog.d/7253-gc-gate-main-line-run.md line 40, add the seed to the
14,373-minor verification environment. In
changelog.d/7270-rest-and-same-module-call-argument-rooting.md lines 55-56, add
the seed to both rest and same-module call rows. In
changelog.d/7280-optional-param-and-dynamic-construct-rooting.md line 67, add
the seed to the six-unit-reproducer environment. In
changelog.d/7317-seeded-gc-schedule-fuzzing.md lines 126-130, separate the
unseeded OFF-state trace from seeded rate-1 arms and explicitly name the seed
value for each ON-state trace environment.

In `@run_parity_tests.sh`:
- Around line 447-454: Update normalize_output’s sed filter to remove only the
known seeded GC schedule startup and exit diagnostic formats, rather than every
line beginning with “[gc-schedule]”. Preserve program output with that prefix
while continuing to strip the runtime-generated diagnostics before parity
comparison.

In `@scripts/gc_instrument_smoke.sh`:
- Line 3: Update the overview comment in gc_instrument_smoke.sh to include
PERRY_GC_SCHEDULE_RATE alongside PERRY_GC_SCHEDULE_SEED, so it documents both
scheduling controls exercised by the script.
- Line 214: The zero-probe diagnostic error message does not match the arm
number being tested. Locate the zero-probe error message that currently reports
"arm 4" and update it to report "arm 7" to align with the arm label shown in the
echo statement at line 214 for the quarantine test section, ensuring the failure
message correctly identifies which arm actually ran.
- Around line 252-253: Update the final summary near the retirement and
quarantine messages to avoid claiming zero retirements or program correctness
across all arms without corresponding assertions. Report the measured pressure
and rate retirement counts separately, and state the quarantine result
independently; alternatively, add explicit assertions for pressure_retired == 0
and Arm 7 probe-output correctness before making those claims.

In `@test-parity/gc_repsel_corpus.txt`:
- Around line 521-522: The measurement records in
test-parity/gc_repsel_corpus.txt document configuration requirements for
reproducing results but omit the PERRY_GC_SCHEDULE_SEED value that
PERRY_GC_SCHEDULE_RATE depends on. At lines 521-522 (the dynamic-construction
measurement record), add PERRY_GC_SCHEDULE_SEED=1 alongside POLLS=1 and RATE=1,
or explicitly note that the seed value is derived from the test harness. Apply
the same fix at lines 558-560 (the optional-parameter measurement record) to
ensure both documented scenarios include the complete seed specification needed
for reproducibility.

---

Outside diff comments:
In `@changelog.d/7317-seeded-gc-schedule-fuzzing.md`:
- Around line 142-144: Reconcile the runtime test-count claims in the changelog
entry: verify the command and feature set used for the reported run against the
latest PR result, then update the embedded test counts and run details to
exactly match the current supporting execution. Remove or revise the stale
comparison if it no longer reflects that run.

In `@docs/statepoint-gc-experiment.md`:
- Around line 933-942: The bullet point stating "scanning is macOS/Mach-O-only"
contradicts the platform verification reported elsewhere in the document (x86-64
and AArch64 Linux support at lines 589-613). Update this bullet to accurately
reflect the current platform support including Linux platforms, or if this
limitation applies only to an earlier prototype version, explicitly label it as
such to clarify the scope and timeline of the constraint.

---

Duplicate comments:
In `@docs/src/internals/gc-rooting-invariant.md`:
- Around line 281-285: The paragraph currently applies the ~3/N statistical
bound to fixed-seed repetitions without clarifying that this bound is invalid
for that scenario. Revise the text to explicitly state that re-running the same
binary with fixed seeds provides no statistical bound on the true bug rate. Then
limit the ~3/N bound statement to apply only when runs use independent schedules
or workloads, making clear the distinction between replayed runs (which don't
accumulate statistical evidence) and varied runs (which do).

🪄 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: f400a510-9796-4177-b65b-ed66f6000c5d

📥 Commits

Reviewing files that changed from the base of the PR and between ca397ef and 027e792.

📒 Files selected for processing (30)

• .github/workflows/test.yml
• CLAUDE.md
• changelog.d/7196-gc-rooting-bug-instruments.md
• changelog.d/7219-registry-gc-unrooted-caches.md
• changelog.d/7227-regexp-receiver-rooting-and-alloc-re-audit.md
• changelog.d/7253-gc-gate-main-line-run.md
• changelog.d/7270-rest-and-same-module-call-argument-rooting.md
• changelog.d/7276-interned-string-cache-root-coverage.md
• changelog.d/7280-optional-param-and-dynamic-construct-rooting.md
• changelog.d/7311-dep-scale-corpus-and-root-reload.md
• changelog.d/7317-seeded-gc-schedule-fuzzing.md
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/policy.rs
• crates/perry-runtime/src/gc/schedule.rs
• crates/perry-runtime/src/gc/tests/fromspace_protect.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• crates/perry-runtime/src/gc/zeal.rs
• crates/perry-runtime/src/object/class_registry/construct.rs
• docs/src/internals/gc-rooting-invariant.md
• docs/src/internals/memory-model.md
• docs/src/internals/rfc-rooting-by-construction.md
• docs/statepoint-gc-experiment.md
• run_parity_tests.sh
• scripts/gc_instrument_smoke.sh
• test-files/test_gap_gc_call_argument_rooting.ts
• test-files/test_gap_gc_regexp_receiver_rooting.ts
• test-files/test_gap_gc_rest_argument_rooting.ts
• test-files/test_gap_gc_same_module_call_argument_rooting.ts
• test-parity/gc_repsel_corpus.txt

💤 Files with no reviewable changes (1)

• crates/perry-runtime/src/gc/zeal.rs

🚧 Files skipped from review as they are similar to previous changes (5)

• crates/perry-runtime/src/gc/policy.rs
• crates/perry-runtime/src/gc/mod.rs
• crates/perry-runtime/src/gc/tests/schedule.rs
• crates/perry-runtime/src/arena/quarantine.rs
• crates/perry-runtime/src/gc/schedule.rs

[coderabbitai]

✅ Action performed

Comments resolved. Approval is disabled; enable reviews.request_changes_workflow to allow explicit top-level @coderabbitai resolve or @coderabbitai approve commands.

[jdalton]

@coderabbitai resolve

[coderabbitai]

✅ Action performed

Comments resolved. Approval is disabled; enable reviews.request_changes_workflow to allow explicit top-level @coderabbitai resolve or @coderabbitai approve commands.

[jdalton]

@coderabbitai resolve

[coderabbitai]

✅ Action performed

Comments resolved. Approval is disabled; enable reviews.request_changes_workflow to allow explicit top-level @coderabbitai resolve or @coderabbitai approve commands.

[jdalton]

Direction change since the previous comment, and a fresh push (f3af2f0c3, rebuilt on e1d27b6af): this PR no longer removes PERRY_GC_ZEAL. The breaking ! is gone from the title; the seeded schedule now lands alongside zeal, and the removal question moves to a follow-up where it can be argued on current facts.

What forced the rethink: within an hour of the previous rebase, main landed #7729, which rebuilds zeal as allocation-paced (PERRY_GC_ZEAL_ALLOC_KB, so the instrument terminates on real workloads) with its own termination gate — plus #7735's poll-arming word. So "rate 1 is an exact zeal replacement" stopped being true (rate 1 is ordinal-paced every-poll — precisely the non-terminating behavior #7728 fixed), and upstream is clearly still investing in the knob. Deleting it out from under that work, hours after it merged, is not this PR's call to make.

What coexistence means concretely in this push

• Zeal's files, tests, smoke arm (gc: PERRY_GC_ZEAL + PERRY_GC_VERIFY_EVACUATION reports a stale forwarded pointer in shadow-stack roots (10/10, pre-existing, no CI arm sets the pair) #7254's ZEAL+VERIFY pairing), and gc: PERRY_GC_ZEAL forces a collection at EVERY back-edge poll, so zeal no longer terminates on real workloads #7728 pacing are untouched — byte-identical to main.
• The two modes compose at three seams, each additive: js_gc_loop_safepoint_armed (when zeal is off, a resolved seed descends so the ordinal can tick; when zeal is on, its pacing owns the poll arm), gc_safepoint_moving_minor's nothing-due branch (zeal first, then the seed's selection — one collection is never counted by both forced-counters, pinned by a new test, a_collection_zeal_and_the_schedule_both_force_is_counted_once_as_zeals), and gc_force_evacuate_enabled() (either mode implies it, unconditionally per gc: PERRY_GEN_GC_EVACUATE=0 moves zero cells on all 12 gc-ratchet probes — the knob's off-state is unexercised #7611).
• poll_arm.rs::resolve_poll_seed keeps the startup seed when the schedule is on — without this one line a schedule-only run would disarm its own polls at the first back-edge and the whole mode would be silently dead (the exact "gate runs but its subject never did" shape).
• The schedule's exit summary now also prints gc: zeal + compiled loop polls performs zero copying minors on compute-only benches — green instrument runs may be vacuous #7604's liveness trio (copying_minors= moved_objects= loop_polls=) so a sweep can tell a clean run from a vacuous one.
• The forced-evacuation implication is unconditional for the seed, same as gc: PERRY_GEN_GC_EVACUATE=0 moves zero cells on all 12 gc-ratchet probes — the knob's off-state is unexercised #7611 made it for zeal — an earlier draft's PERRY_GEN_GC_EVACUATE=0 precedence rule referenced a knob main has deleted, and would have resurrected the exact ambient-veto footgun it was deleted for.
• Stale claims fixed: PERRY_GC_MOVING_LOOP_POLLS is default ON since #7721, and the docs/scripts this PR touches now say so.

Validation: cargo check -p perry-runtime clean; 67 targeted tests green under --test-threads=1 across gc::tests::schedule (now 12), gc::tests::fromspace_protect (zeal tests + the schedule/protection compose test), gc::tests::evacuation, gc::zeal (incl. #7728 pacing and #7604 verdict tests), and gc::poll_arm; scripts/check_file_size.sh OK.

Known and deliberately not buried: CI triage against the previous head found one real defect owned by this PR — test_gap_buffer_own_props SIGSEGV on conformance-smoke shard 8 (its sibling test_gap_buffer_own_prop_shadow_intrinsic_6405 already crashes on main's shard 7; the likely story is one shared unrooted temporary in the Buffer own-prop enumeration path that this PR's extra collections widen from one test to two). The Linux repro hunt for that is next; the other 17 failing checks on the previous run reproduce byte-for-byte on this PR's parent and are main-side debt.

A follow-up PR will re-propose the zeal removal properly — porting the #7684 liveness counters to a neutral home, the #7604 verdict onto the schedule's endpoint, and #7728's allocation pacing into the schedule — stacked on this one so the diff collapses when this merges.