Run large full cycle-collector passes on idle CPUs in speed builds

[cramforce]

Summary

In executables built with --optimization=speed on Linux and Darwin, a full pass over at least 100,000 live cycle-headered objects runs markRoots, markGray and scan on helper threads together with its own thread. Settling (white filtering, re-buffering, teardowns, re-arming) stays on the owner, so free_fn, weak-reference disposal and FinalizationRegistry notifications run on the same thread at the same point as before. The result is the sequential black/white partition; only teardown order within a pass can differ.

• Idle CPUs only: the CPUs available to the process minus its running or runnable threads. Linux reads /proc/self/task/*/stat; Darwin uses task_threads + thread_info (new). The count is checked once per large pass. Helpers are created lazily, block all signals, and are capped at 15. One parallel pass runs at a time per process.
• SCR_CYCLE_PARALLEL caps the helpers (0 turns the walk off); SCR_CYCLE_PARALLEL_MIN sets the floor.
• Speed builds only: compiled into every executable, the walk added 6-10 KB of x86-64 code, +10.0% on a 99 KB release program (log-lines). The runtime pack's speed flavor now defines SCR_SPEED. Release, dev and library builds compile the walk out.

Measurements

Where large full passes remain, it removes most of their time. With SCR_CYCLE_GROWTH_CAP=1 (5 rounds, parallel vs sequential):

	Excalidraw	Playwright	TypeORM	self-check
single-threaded	-7.1%	-4.6%	-8.7%	-5.7%
--checkers 8	-1.9%	-3.9%	-1.9%	+3.7%

On the default schedule after PR 1, the remaining full passes are small: full-pass time drops 89 -> 32 ms on the self-check, 130 -> 39 on TypeORM and 104 -> 36 on Excalidraw. The wall-time effect is within noise:

run	Excalidraw	Playwright	TypeORM	self-check
single-threaded, 10 rounds	+1.4%	-2.2%	-1.3%	-0.7%
single-threaded, 5 rounds (final build)	+5.0%	-1.2%	-1.5%	-3.2%
--checkers 8, 10 rounds	-1.5%	+1.7%	+0.5%	-1.5%

RSS +0.3% to +1.3%; user CPU +2-3% single-threaded. On #833's widening alone (without PR 1), the prototype gave -1.2% to -6.2% single-threaded (5 rounds).

Sizes: tsc-ts 23,676,592 -> 23,685,776 bytes (+9,184). Runtime suite in speed builds: +1.1% to +9.7% (geomean +4.0%), time geomean +0.1% (all neutral), peak RSS +0.3%. Release builds are unchanged.

Tests

• test_cycle: randomized graphs (sparse, hubs of 1000-5000 children, long chains cut open; 3 seeds × 20,000 nodes) checked against the test's own reachability and expected counts.
• cycle.test.ts: the whole suite with every full pass forced parallel. That covers a plain speed build at 3 helpers and a worker build at 1/3/7 helpers (and 0) under ASan+UBSan, plus the worker build under ThreadSanitizer at 1/3/7 helpers. It passes on macOS arm64 and Linux x64.
• Mutations caught: double blackening, seeding scan from every gray node, whitening black nodes, gray claim by store instead of exchange, and a non-atomic decrement (also flagged by TSan).
• Docs: NEXT_DIST_DIR=.next-check pnpm check passes (23/23 route tests).

Open question for review

On tsc-ts's default schedule after PR 1, this PR's wall-time effect is within noise. It pays where large passes remain: memory-capped runs and larger heaps. It costs about 430 lines of concurrent code and 4% of speed-build size. Whether to land it is a judgment call.

Draft: after the faster widening (previous PR) this adds little to tsc-ts by default (−2.2% to +1.7%); it pays where large passes remain (−5 to −9% with SCR_CYCLE_GROWTH_CAP=1). Kept ready for memory-capped runs and larger heaps; to be revisited after the nursery-pass work.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
scriptc	Ready	Preview, v0	Oct 11, 2026 3:46am UTC