alloc_phase.SealedPhaseAllocator

1/// Enforces strict lifecycle boundaries around a backing allocator by panicking2/// whenever caller code attempts a raw operation outside the permitted phase.3/// During initialization, the guard permits all four raw operations:4/// allocation, resizing, remapping, and freeing. Once sealed to the steady5/// phase, every raw allocator call is considered a violation: the guard6/// increments the corresponding violation counter and explicitly panics before7/// dispatching to the backing allocator, never returning `error.OutOfMemory` to8/// signal phase errors. During teardown, freeing remains permitted, but9/// allocation, remapping, and resizing are treated as violations and panic,10/// including requests that attempt to shrink existing allocations.11///12/// The guard stores its state in a separately allocated control block, allowing13/// wrapper copies and issued `std.mem.Allocator` handles to share the same14/// lifecycle phase, counters, and backing allocator. Because `Allocator.ptr`15/// references this shared control block directly, moving or copying the wrapper16/// preserves issued handles. Lifecycle transitions occur through explicit calls17/// to `seal`, `abortInitialization`, and `beginTeardown`, and any invalid or18/// duplicate transition panics in all build modes. This guard intercepts only19/// raw calls routed through its own handles: it does not observe global20/// allocator usage, distinct allocator handles, operating system calls, or21/// backing allocator internal operations. It enforces no startup allocation22/// byte budget and provides no guarantee that runtime workloads fit23/// preallocated memory.24pub const SealedPhaseAllocator = PhaseAllocator(.panic);

1/// Enforces strict lifecycle boundaries around a backing allocator by panicking2/// whenever caller code attempts a raw operation outside the permitted phase.3/// During initialization, the guard permits all four raw operations:4/// allocation, resizing, remapping, and freeing. Once sealed to the steady5/// phase, every raw allocator call is considered a violation: the guard6/// increments the corresponding violation counter and explicitly panics before7/// dispatching to the backing allocator, never returning `error.OutOfMemory` to8/// signal phase errors. During teardown, freeing remains permitted, but9/// allocation, remapping, and resizing are treated as violations and panic,10/// including requests that attempt to shrink existing allocations.11///12/// The guard stores its state in a separately allocated control block, allowing13/// wrapper copies and issued `std.mem.Allocator` handles to share the same14/// lifecycle phase, counters, and backing allocator. Because `Allocator.ptr`15/// references this shared control block directly, moving or copying the wrapper16/// preserves issued handles. Lifecycle transitions occur through explicit calls17/// to `seal`, `abortInitialization`, and `beginTeardown`, and any invalid or18/// duplicate transition panics in all build modes. This guard intercepts only19/// raw calls routed through its own handles: it does not observe global20/// allocator usage, distinct allocator handles, operating system calls, or21/// backing allocator internal operations. It enforces no startup allocation22/// byte budget and provides no guarantee that runtime workloads fit23/// preallocated memory.24pub const SealedPhaseAllocator = allocator.SealedPhaseAllocator;