feat(fspy): route preload allocations through a lock-free global allocator

[wan9chi]

Alternative to #596. Both PRs solve the same problem; this one exists so CI can price the two approaches against each other on identical workloads. One of them should be closed once the numbers are in.

Motivation

The preload library runs inside libc calls such as open, stat, and execve. Programs are allowed to make these calls from a signal handler, or in the child of fork() in a program with many threads. In both situations, using libc's malloc can hang the program forever: the lock inside malloc may be held by a thread that is paused or no longer exists.

The two approaches

	#596 (per-call arena)	this PR (global allocator)
Coverage	only converted call sites	every allocation in the library, at once
Call-site changes	each one rewritten to allocate in the arena	none
Freeing	whole arena dropped at the end of the call	per allocation, like any allocator
Lifetimes	borrow checker forbids escaping the call	unrestricted
Cost per allocation	pointer bump; ~2 atomics per call	~2 atomics per allocation
Code	~350 lines	~1400 lines

This PR installs one #[global_allocator] in the preload cdylib: power-of-two size classes carve blocks out of 1 MiB mmap'd slabs, freed blocks recycle through per-class Treiber free lists made ABA-resistant by a 40-bit generation tag, and requests larger than the biggest class (or over-aligned) map and unmap directly. All memory comes from anonymous mappings; libc malloc is never called, no locks are taken, and no thread-local state is used, so a thread that vanishes at fork() or is suspended by a signal cannot strand another.

The trade-off in one line: the global allocator converts the whole library immediately but pays its cost on every allocation, while the arena is cheaper per allocation but only covers code that has been rewritten to use it.

Comparing

This PR carries the same access-relative benchmark suite as #596, so both report the same rows against the same base. access prices the absolute-path lane (a borrowed pointer, no directory resolution); access-relative prices the lane that resolves the working directory and joins a path — where #596's arena is actually used.

Read the two benchmark comments together: #596 changes one hot call site, this one changes the allocator underneath all of them.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[github-actions]

fspy benchmark

linux

dynamic/launch             change  +5.30%  [ +1.33% .. +10.95%]  overhead   +63.38%
dynamic/access             change  -0.41%  [ -1.43% ..  +0.67%]  overhead    +6.26%
dynamic/access-relative    change  +4.16%  [ +2.88% ..  +5.50%]  overhead   +61.64%
static/launch              change  +0.53%  [ -4.97% ..  +6.16%]  overhead  +158.12%
static/access              change  -0.23%  [ -1.52% ..  +1.85%]  overhead  +839.78%
static/access-relative     change  +0.15%  [ -0.89% ..  +1.52%]  overhead +1357.99%

macos

dynamic/launch             change  -0.54%  [ -4.69% ..  +4.15%]  overhead  +219.80%
dynamic/access             change  -0.35%  [ -7.38% ..  +6.13%]  overhead    +3.46%
dynamic/access-relative    change  +0.79%  [ -8.15% .. +29.12%]  overhead  +386.82%

windows

dynamic/launch             change  +0.58%  [ -9.67% ..  +9.22%]  overhead   +25.97%
dynamic/access             change  -0.17%  [ -2.26% ..  +2.46%]  overhead    +1.96%
dynamic/access-relative    change  +0.54%  [ -1.18% ..  +2.37%]  overhead    +1.83%

[wan9chi]

Comparison with #596

Both PRs now have benchmark runs against the same base (main with #597 merged), carrying the same suites. Linux is the only platform where either signal clears the noise; macOS and Windows are within their intervals on every row for both.

linux row	#596 per-call arena	#599 global allocator
dynamic/access	-0.81% [-5.01 .. +1.06]	-0.41% [-1.43 .. +0.67]
dynamic/access-relative	+2.70% [+1.41 .. +4.47]	+4.16% [+2.88 .. +5.50]
dynamic/launch	+0.56% [-4.41 .. +5.51]	+5.30% [+1.33 .. +10.95]
static/* (musl control)	~0%	~0%

Reading:

• access is free for both. Neither design touches the absolute-path lane — it borrows the caller's string and never allocates — so both rows sit on zero, as they should. This is the control that says the measurement is sane.
• access-relative costs both, and the arena costs less. +2.70% vs +4.16%, intervals barely overlapping. Notable because this is the lane the global allocator was supposed to win: it covers the ~4 KB PathBuf that getcwd allocates, which the arena leaves on malloc. Covering more allocations did not pay for itself — glibc's malloc is very good at exactly this shape (repeated same-size allocation, thread-local cache), so replacing it costs more than it saves, on top of which the size-class allocator pays ~2 atomics per allocation where the arena pays them per call.
• launch separates them. +5.30% [+1.33 .. +10.95] for the global allocator vs +0.56% for the arena. Process startup is allocation-heavy (payload decode, env parsing, IPC setup) and every one of those now goes through the size-class allocator, including first-touch page faults on fresh slabs. The arena's unallocated() construction costs nothing until something allocates, so startup is untouched.

Recommendation

Land #596, close this one. It is cheaper on every row that moved, one quarter of the code (~350 vs ~1400 lines), and its lifetimes are compiler-enforced rather than unrestricted. The one thing this PR does better — covering allocations nobody has converted yet — is exactly what the remaining migration work in #596 addresses incrementally, and the numbers say that blanket coverage is not worth what it costs.

Worth keeping from this branch: it is the only measurement showing what full allocator replacement costs, which is useful if the remaining conversions ever stall.

🤖 Generated with Claude Code