perf: optimize artifact dependencies, and fail the build when a consumer does not - #597
Merged
Merged
Conversation
fspy benchmarklinuxmacoswindows |
wan9chi
force-pushed
the
claude/fspy-artifact-opt-level
branch
from
August 9, 2026 01:11
b155abe to
18f0aa2
Compare
wan9chi
force-pushed
the
claude/fspy-artifact-opt-level
branch
from
August 9, 2026 01:28
18f0aa2 to
f8754c5
Compare
…mer does not Cargo compiles artifact dependencies declared under [build-dependencies] with the build-override profile — opt-level 0, default codegen-units — even in release builds (rust-lang/cargo#16719), and it only reads profiles from the root manifest of the workspace being built. Their output still lands under target/<triple>/release/, so nothing reports the omission. Three workspace artifacts are build-dependencies and have been shipping unoptimized: fspy_preload_unix and fspy_preload_windows (injected into every traced process, running inside every intercepted libc call), and vt_client_napi. Set opt-level 3 for them, restore codegen-units 1 (the host profile drops it), and restate strip = "symbols" (a package override otherwise resets inherited strip to "debuginfo"). Because those profile entries live in the root manifest, they do not reach workspaces that consume these crates as dependencies — vite-plus builds the preload at opt-level 0 today and would keep doing so. So each artifact crate now checks its own OPT_LEVEL in its build script and fails a release build that is unoptimized, printing the exact profile block to add. Debug builds are unaffected, and ALLOW_UNOPTIMIZED_ARTIFACTS=1 waives the check. Measured on x86_64 Linux, tracked opens with the optimized unix preload (batch median per 8 opens): access -24.8%, access-relative -19.1%. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
wan9chi
force-pushed
the
claude/fspy-artifact-opt-level
branch
from
August 9, 2026 01:33
f8754c5 to
dbccfd2
Compare
wan9chi
marked this pull request as ready for review
August 9, 2026 01:41
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
wan9chi
added a commit
that referenced
this pull request
Aug 9, 2026
Part of #605 — this lands the malloc-class fix (the largest of the hazards there); the lazy-dlsym, hot-path panic, TLS reentrancy, and posix_spawn-thread items remain follow-ups. The benchmark suite that prices this change merged in #602. ## 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 preload library still allocates through `malloc` today, so a traced program can hang in exactly these situations. ## What this does Adds a new crate, `sigsafe`: Unix syscall wrappers that are safe to call where libc is not — in signal handlers, in fork children, before libc has finished initializing. Its [README](https://github.com/voidzero-dev/vite-task/blob/claude/fspy-libc-async-signal-safe-129134/crates/sigsafe/README.md) states the three rules everything in it follows: syscalls only (never through libc on Linux), no locks and no hidden state, and no global allocation. **The no-libc rule is enforced at compile time.** rustix can be built with a libc backend, and anything in the dependency graph — including crates outside this repository — can select it; no build script can detect the feature-unification case. So `sigsafe`'s `lib.rs` references `rustix::runtime`, a module that exists only in rustix's raw-syscall build: selecting the libc backend makes the crate fail to compile instead of silently losing the guarantee. On top of the first wrappers (`mm::mmap_anonymous`, `mm::munmap`, `param::page_size`) sits `sigsafe::alloc`, allocation that never touches malloc, in three layers with only the top exposed: - `MmapAllocator` — every allocation asks the kernel for fresh memory pages through `sigsafe::mm`. It keeps no state of its own, so there is nothing a signal or a `fork()` can catch locked or half-written. - `ChunkPool` — keeps up to 64 freed 64 KiB chunks in a fixed array of atomic pointers, so the next call can reuse memory without asking the kernel again. Taking or returning a chunk is one atomic swap per slot, never a lock, and a thread that disappears mid-operation can strand at most the one chunk it held. - `alloc::arena()` — the only public function. It hands one intercepted call its own bump arena (a `bump_scope::Bump`) that draws chunks from the pool and returns them when the call ends. Values allocated in the arena cannot outlive the call; the borrow checker enforces it. Uses the arena in one place to start: `RawExec::to_c_str_array`, which builds the NULL-terminated argv/envp pointer arrays that an intercepted exec hands to the real call, then drops them when it returns. That temporary's lifetime is already exactly a bump arena's, so the change is nine lines and adds no `unsafe`. It has to come off malloc because exec runs in the child of `fork()` in multithreaded programs — `posix_spawn` forks then execs — where malloc's lock may be held by a thread that no longer exists. Both platforms take this path on every intercepted exec. The strings the array points at are still owned by `Exec` and still come from malloc, as does the rest of the preload; converting them is follow-up. This change establishes the crate, the layers, and the lifetime discipline in the smallest place all three apply. ## Benchmark The `access-relative` suite (#602) was added while this PR still used the arena for the fd-relative join, and it earned its keep twice: an early run showed **+29%** on Linux, which turned out to be the preload building without optimizations (fixed by #597), and the corrected runs showed the arena join costing ~+3% over `PathBuf::push` — which is why the join reverted and the arena moved to `execveat`. The investigation is written up in [this comment](#596 (comment) thread. With the join reverted, both suites should sit at baseline. ## Commits The first commit is an earlier version of the allocator — one lock-free size-class allocator installed as the preload's `#[global_allocator]` — kept so the two designs can be compared; #599 measured that design end to end and lost. The second commit replaces it with the arena design above. The third moves the allocator into the new `sigsafe` crate as `sigsafe::alloc`, adds `mm`/`param` and the compile-time backend enforcement, and adds the README. The fourth moves the arena use from the join to `execveat` and fixes the dangling pointer there. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
wan9chi
added a commit
that referenced
this pull request
Aug 11, 2026
## Motivation #597 worked around Cargo compiling `[build-dependencies]` artifact deps with the build-override profile (opt-level 0 in release; rust-lang/cargo#16719) using per-package `[profile.release.package.*]` overrides plus the `artifact_profile` build-script guard. The next PR in this stack (#636) moves the artifact cdylibs to `[dependencies]`, where the normal release profile applies in this workspace and every downstream one — making both the overrides and the guard dead machinery. ## What this does Reverts #597 (5ed7a5a): removes the three profile-override blocks, the `artifact_profile` crate, and its build-script guard calls from the preload and napi crates. Note: artifact cdylibs build unoptimized between this PR and #636; the stack lands together. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Cargo compiles artifact dependencies declared under
[build-dependencies]with the build-override profile — opt-level 0 — even in release builds. It is the[build-dependencies]placement, not theartifact = ...key, that triggers this (artifact deps under[dependencies]get the normal profile). The output still lands undertarget/<triple>/release/, so nothing reports the omission. See rust-lang/cargo#16719; the per-package override used here is what maintainers recommend (rust-lang/cargo#11680).Three workspace artifacts are build-dependencies and have been shipping unoptimized: the two preload libraries — injected into every traced process, running inside every intercepted libc call — and
vt_client_napi.What this does
Sets the profile. A
[profile.release.package.<name>]block per artifact, withopt-level = 3,codegen-units = 1(the host profile drops the workspace setting), andstrip = "symbols"(a package override otherwise resets an inheritedstripto"debuginfo", which would leave the preload.so— embedded into thefspybinary — larger than intended).Then checks that it worked. Profiles only take effect from the root manifest of the workspace being built, so these entries do not reach workspaces that consume these crates. vite-plus builds the preload at opt-level 0 today and would keep doing so after this merges, silently. Rather than rely on every consumer knowing, each artifact crate now inspects its own
OPT_LEVELin its build script and fails a release build that is unoptimized:Debug builds are unaffected, since opt-level 0 is correct there.
Only the optimization level is checked: Cargo passes
OPT_LEVEL,DEBUGandPROFILEto build scripts, but notcodegen-unitsorstrip, so those cannot be verified — which is why the message prints the whole block rather than the one setting it can see. The check lives in each artifact crate rather than inmaterialized_artifact_buildbecause that crate runs from the consuming build script, which reports its ownOPT_LEVEL(3) while the artifact it just embedded was built at 0.This is a breaking change for downstream workspaces. vite-plus will fail to build until it adds the three blocks to its root
Cargo.toml— it already uses that pattern forvite_trampolineandvite_installer. That failure is the point: the alternative is shipping a preload that costs ~25% on every intercepted call, with no signal at all.Measurements
x86_64 Linux, benchmark launcher built with vs. without the profile change, batch median per 8 tracked opens:
Raising the dependency subtree's pre-LTO opt-level on top of this measured within noise — fat LTO re-optimizes the merged module at the cdylib's opt-level — so this keeps the smaller, cdylib-only override set.
🤖 Generated with Claude Code