Skip to content

refactor(fspy-client): accept allocators from the interception layer - #685

Draft
wan9chi wants to merge 1 commit into
agent/fspy-channel-conf-viewfrom
agent/fspy-toplevel-allocators
Draft

refactor(fspy-client): accept allocators from the interception layer#685
wan9chi wants to merge 1 commit into
agent/fspy-channel-conf-viewfrom
agent/fspy-toplevel-allocators

Conversation

@wan9chi

@wan9chi wan9chi commented Aug 18, 2026

Copy link
Copy Markdown
Member

Motivation

fspy_client_unix still created pooled bumps in the middle of call stacks for per-interception temporaries: try_handle_open drew one for path resolution, and RawExec's pointer-array build drew another during exec handling. Allocator choices belong at the top of the call stack, with everything below accepting a generic allocator — the layering the rest of the stack established.

  • try_handle_open, handle_exec, and RawExec::from_exec accept the allocator for their transient path and pointer-array storage.
  • The unix exec wrapper takes the allocator from each interception, so execveat — which already owns a bump for its path resolution — shares that one bump with the exec-argument rebuild instead of drawing a second chunk from the pool.

fspy_client_unix no longer creates any allocator.

🤖 Generated with Claude Code

@wan9chi wan9chi changed the title agent/fspy toplevel allocators refactor(fspy-client): accept allocators from the interception layer Aug 18, 2026
@github-actions

github-actions Bot commented Aug 18, 2026

Copy link
Copy Markdown

fspy benchmark

linux

dynamic/launch             change  -1.13%  [-13.09% .. +10.20%]  overhead  +273.63%
dynamic/access             change  -0.44%  [ -1.58% ..  +0.99%]  overhead    +6.77%
dynamic/access-relative    change  +0.91%  [ -0.45% ..  +1.75%]  overhead   +55.33%
dynamic/access-contended   change  -1.33%  [ -6.45% ..  +3.53%]  overhead    +6.94%
static/launch              change  +1.24%  [ -8.12% ..  +9.67%]  overhead  +687.37%
static/access              change  +0.58%  [ -7.75% .. +12.73%]  overhead  +748.11%
static/access-relative     change  +0.80%  [ -4.90% ..  +3.71%]  overhead +1146.30%
static/access-contended    change  -0.92%  [ -3.37% ..  +2.51%]  overhead +3263.56%

macos

dynamic/launch             change  +0.57%  [ -7.39% ..  +7.52%]  overhead  +237.84%
dynamic/access             change  +0.37%  [-10.98% .. +14.61%]  overhead    +4.09%
dynamic/access-relative    change  +0.64%  [-11.47% .. +19.85%]  overhead  +249.81%
dynamic/access-contended   change  +1.15%  [-12.26% ..  +8.91%]  overhead    +2.91%

windows

dynamic/launch             change  -1.28%  [ -8.72% ..  +6.17%]  overhead   +25.44%
dynamic/access             change  +1.49%  [ -3.76% .. +30.14%]  overhead    +2.99%
dynamic/access-relative    change  -0.88%  [-16.36% ..  +2.46%]  overhead    +2.29%
dynamic/access-contended   change  +2.34%  [ -3.52% .. +13.14%]  overhead    +2.29%

@wan9chi
wan9chi force-pushed the agent/fspy-toplevel-allocators branch 2 times, most recently from a7eb5cd to 9422045 Compare August 18, 2026 09:23
@wan9chi
wan9chi force-pushed the agent/fspy-toplevel-allocators branch from 9422045 to eccff03 Compare August 18, 2026 09:56
@wan9chi
wan9chi force-pushed the agent/fspy-toplevel-allocators branch 2 times, most recently from ba2af84 to adc4e90 Compare August 18, 2026 10:21
@wan9chi
wan9chi force-pushed the agent/fspy-toplevel-allocators branch from adc4e90 to 38ed207 Compare August 18, 2026 15:33
@wan9chi
wan9chi force-pushed the agent/fspy-toplevel-allocators branch from 38ed207 to 8127650 Compare August 18, 2026 15:58
The pooled bumps that fspy_client_unix created internally for
per-interception temporaries now come from the interception layer, so
allocator choices live only at the top of the call stack:

- try_handle_open, handle_exec, and RawExec::from_exec accept the
  allocator for their transient path and pointer-array storage.
- The unix exec wrapper takes the allocator from each interception, so
  execveat shares its path-resolution bump with the exec-argument
  rebuild instead of drawing a second chunk from the pool.

fspy_client_unix no longer creates any allocator, and its
fspy_nostd_alloc dependency goes away with the last use.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@wan9chi
wan9chi force-pushed the agent/fspy-toplevel-allocators branch from 8127650 to 65010b7 Compare August 18, 2026 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant