Expand description
Per-request bump-allocator arena (#463 scaffolding).
The minimal lifecycle machinery for request-scoped allocations.
See docs/design/jit-roadmap.md for the broader plan and
issue #463 for the perf rationale.
§Status: scaffolding only
This module is wired through the EffectHandler trait so the VM
can call enter_request_scope / exit_request_scope at the
right boundaries — but the arena is not yet plumbed into
Value allocations. Today every MakeRecord, MakeList,
Str still goes through the global allocator. The arena gets
created and dropped at each request boundary as a no-op proof
that the lifetime machinery works, ready for a follow-on slice
to route actual allocations.
§Why scaffolding-first
Routing Value’s heap parts (Box<IndexMap<…>>,
VecDeque<Value>, Vec<u8>, …) through the arena requires
either a lifetime parameter on Value (massive churn — every
one of the ~60 as_int / as_str / as_bool call sites in
the codebase) or an arena-id tag on every heap allocation
(Drop impl must dispatch to the right allocator). Both are
sized in months — see the JIT roadmap doc.
Landing the lifecycle first means future Value-rep changes have a stable trait surface to plug into. The cost today is one allocator construction + drop per HTTP request — negligible compared to the request itself.
§Lifetime model
- One arena per request handler invocation.
- Arena owns a bump-allocated page chain.
allocis a pointer-bump on the current page; full pages chain into aVec<Page>and the whole vec drops at scope-exit. - Cannot outlive the request — values built into the arena must not escape via channels / captures / closures. That’s why the verifier-based escape analysis in #464 is a prerequisite for actually routing allocations through it; for now nothing escapes because nothing uses it.