Bounded global allocator

Workspace infrastructure providing a static, pre-allocated, fixed-block global allocator for taktora binaries that must give compile-time guarantees on memory usage. The crate (taktora-bounded-alloc) is independent of taktora-executor but composes naturally with it — No heap allocation in dispatch (REQ_0060) (zero-alloc steady-state dispatch) is tested by a counting allocator and enforced in deployed binaries by registering this crate’s allocator as #[global_allocator].

Umbrella feature

Feature: Bounded global allocator FEAT_0040
status: open
is satisfied by: REQ_0300, REQ_0301, REQ_0302, REQ_0303, REQ_0304

A reusable #[global_allocator] implementation that draws every allocation from a statically-sized, pre-allocated arena with hard caps on both per-allocation size and total live block count. Returns null when either cap is reached, so allocation failure is bounded and observable rather than producing OOM-driven address space growth. An optional “lock-after-init” mode causes any allocation attempt after a designated point in the program to panic immediately, making the steady-state zero-allocation invariant required by No heap allocation in dispatch (REQ_0060) enforceable at runtime in deployed binaries.

Requirements

Requirement: Pre-allocated fixed-block arena REQ_0300
status: open
satisfies: FEAT_0040
is refined by: ADR_0012, IMPL_0002
is implemented by: BB_0024
is verified by: TEST_0180, TEST_0181

The allocator shall serve every allocation from a single statically-sized arena whose total capacity is MAX_BLOCKS * BLOCK_SIZE bytes. MAX_BLOCKS and BLOCK_SIZE shall be compile-time const generics on the allocator type; the arena and the allocator’s own bookkeeping (free bitmap, counters, lock flag) shall live in static storage and shall not themselves invoke any heap allocation. The allocator shall not grow the arena at runtime.
Requirement: Fail-closed on cap overrun REQ_0301
status: open
satisfies: FEAT_0040
is refined by: IMPL_0002
is implemented by: BB_0024
is verified by: TEST_0180

When an allocation request cannot be satisfied — because layout.size() > BLOCK_SIZE, layout.align() > BLOCK_SIZE (the per-block alignment derives from BLOCK_SIZE), or the bitmap has no free block — the allocator’s alloc method shall return a null pointer. Rust’s default alloc_error_handler shall thereby abort the process, producing a fail-closed outcome rather than undefined behaviour or silent fallback to the system allocator.
Requirement: Lock-after-init panic mode REQ_0302
status: open
satisfies: FEAT_0040
is refined by: IMPL_0002
is implemented by: BB_0024
is verified by: TEST_0182

The allocator shall expose a lock(&self) method that flips an internal AtomicBool (Release ordering). After lock returns, every subsequent call to alloc (including alloc_zeroed and realloc) shall panic immediately rather than returning a pointer. Binaries using this mode shall configure panic = "abort" in their Cargo profile so the panic itself does not attempt to allocate the unwinder’s payload string. The lock is one-way; there is no unlock method.
Requirement: Allocation accounting API REQ_0303
status: open
satisfies: FEAT_0040
is refined by: IMPL_0002
is implemented by: BB_0024
is verified by: TEST_0183

The allocator shall expose public methods returning live counts: total successful alloc calls since process start, total successful dealloc calls since process start, and the high-water-mark of simultaneously-live blocks. These counts shall be maintained even when the allocator is registered as #[global_allocator], so test harnesses and observability tools can read steady-state allocation activity without requiring a parallel instrumentation layer.
Requirement: Thread-safe allocation REQ_0304
status: open
satisfies: FEAT_0040
is refined by: IMPL_0002
is implemented by: BB_0024
is verified by: TEST_0184

Concurrent alloc and dealloc calls from multiple threads shall be safe (no torn state, no double-allocation of a block, no double-free) under the standard Rust GlobalAlloc contract. The bitmap shall use AtomicU64 words with compare-exchange-based allocation; the counters shall use appropriate atomic ordering; the lock flag shall use Acquire on read and Release on write.

Safety refinements

The bounded allocator implements safety obligations Bounded allocator hard caps (TSR_0001) and Per-integrity-level allocat... (TSR_0002) derived from the SEooC safety concept (see Technical Safety Concept — TSRs).