fix(gc): pin the two per-thread scanner latches #8552 added (main is red)

[proggeramlug]

Problem

main (3885ba491) is red on the holders gate:

$ python3 scripts/gc_runtime_root_holders.py
crates/perry-runtime/src/messaging.rs:163: GC_SCANNER_REGISTERED: Cell<bool>  [rule T]
crates/perry-runtime/src/object/native_this_alias.rs:70: SCANNER_REGISTERED: Cell<bool>  [rule T]
exit 1

This is an interaction between two PRs that are each correct alone:

• fix(gc): census perry_thread_local holders #8545 taught the census to parse perry_thread_local!, closing gc: gc_runtime_root_holders.py cannot see perry_thread_local! — 248 of ~881 holders invisible #8544.
• fix(gc): register mutable root scanners per thread #8552 replaced process-global scanner-registration latches with per-thread
  Cell<bool> ones.

Before #8545 the census could not see a perry_thread_local! declaration, so
#8552's new latches were invisible. After it, they are visible and unclassified,
and an unclassified holder fails the gate by design.

CI runs the bare invocation (test.yml:411, :1434), which is the failing one.
Worth noting --list exits 0 on the same tree, so a check that used only
--list would show green.

Change

Pin both on the identity-ratcheted frontier.

They are Cell<bool> idempotence flags for ensure_gc_scanner_registered() /
ensure_scanner_registered() — they store a flag, never an address. The tables
whose registration they guard (PORT_STATES, ALIASES) are the holders with GC
standing, and their scanners visit those values.

The frontier rather than a holders verdict is deliberate, and not a
preference: these are rule T (the census cannot see through the type), and the
gate rejects a holders entry for a rule-T declaration as stale. I tried the
verdict first and it stayed red with inventory has 2 stale entries.

Verification

• python3 scripts/gc_runtime_root_holders.py — exit 1 -> 0
• python3 scripts/gc_runtime_root_holders.py --self-test — OK (89 planted
  declarations classified, 68 inventory entries checked)
• Population after fix(gc): census perry_thread_local holders #8545's unmasking: 855 scanned / 621 pinned (was 633
  scanned before it)
• Sabotage check that the gate can still fail for the case gc: gc_runtime_root_holders.py cannot see perry_thread_local! — 248 of ~881 holders invisible #8544 was filed about:
  deleting reg_scanner!(crate::module_require::scan_module_path_roots_mut)
  from gc/mod.rs makes the gate exit 1. fix(gc): census perry_thread_local holders #8545's promise holds.

No version bump.

[coderabbitai]

Warning

Review limit reached

@proggeramlug, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 35 minutes

Limit details: You’ve used all 8 included reviews currently available.

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?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 29a33994-5947-4d35-8b76-2e9de748340e

📥 Commits

Reviewing files that changed from the base of the PR and between 32d37ee and c0e0201.

📒 Files selected for processing (2)

• changelog.d/8557-holders-scanner-latch-frontier.md
• scripts/gc_runtime_root_holders.json

---

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.}

[proggeramlug]

Closing — the same fix already landed as #8558, and this branch has since become unsafe to merge.

We diagnosed the identical breakage independently and within minutes of each other; your analysis is correct and matches mine, including the point that the two source PRs are each right alone and only collide through the identity ratchet.

Two reasons to close rather than merge:

1. fix(gc): pin the scanner latches #8552 added to the root-holder inventory #8558 already pinned both holders. gc_runtime_root_holders is green on main again — verified exit=0, 855 holder declarations scanned, 687 identity-ratcheted.
2. This branch predates fix(compile): land #8553 — require(<builtin>) implies stdlib linking #8556. Its merge base is 3885ba4 and main has moved 2 commits since. Diffed against current main, it reads as removing the require('<builtin>') stdlib-linking fix (require('http') links runtime-only, so stdlib builtins return undefined (ESM import works) #8547) that fix(compile): land #8553 — require(<builtin>) implies stdlib linking #8556 landed. Merging it now would revert that.

Worth recording the shared conclusion: a Cell<bool> cannot hold a heap pointer, so pinning these is record-keeping, not a GC-safety verdict — which is exactly the distinction the gate's own README draws.