Home › allocator

Module allocator

allocator
Stability: unstable — `Layout`, `AllocError` and the `GlobalAllocator` names are settled, but this module is a TRAIT SURFACE with exactly one implementor and that has never been tested. Nothing in `std` is generic over an allocator: every container calls `GlobalAllocator.malloc`/`free` directly, so the abstraction has never had to survive a second backend, and the shape a custom allocator would need (does it get `Layout`, or size + alignment? is `realloc` required or defaulted?) is unanswered by use. Freezing needs a second implementor — an arena or a counting allocator in `tests/` would do — and a decision on whether containers take an allocator parameter the way Zig's and Rust's do. Until then, treat this as the global allocator's own interface rather than as a pluggable one. — stable modules only change additively; this one may still change.

Memory allocation abstractions and global allocator interface.

Stability

unstable — Layout, AllocError and the GlobalAllocator names are settled, but this module is a TRAIT SURFACE with exactly one implementor and that has never been tested. Nothing in std is generic over an allocator: every container calls GlobalAllocator.malloc/free directly, so the abstraction has never had to survive a second backend, and the shape a custom allocator would need (does it get Layout, or size + alignment? is realloc required or defaulted?) is unanswered by use. Freezing needs a second implementor — an arena or a counting allocator in tests/ would do — and a decision on whether containers take an allocator parameter the way Zig's and Rust's do. Until then, treat this as the global allocator's own interface rather than as a pluggable one.

Types

Layout struct
Layout

Describes the size and alignment requirements for a memory allocation.

Fields

NameTypeDescription
sizeusize

Size in bytes.

alignmentusize

Alignment in bytes (must be a power of two).

AllocError enum
AllocError

Memory allocation error variants.

Variants

VariantFieldsDescription
OutOfMemory

Allocator ran out of memory.

Functions

size_would_overflow function
fn(comptime(T) : Type, count : usize) -> bool

Check if allocating count elements of type T would overflow usize.

Parameters

NameTypeNotes
TTypecomptime
countusize

Returns: bool

layout_of function
fn(comptime(T) : Type) -> comptime(Layout)

Get the memory layout (size and alignment) of a type at compile time.

Parameters

NameTypeNotes
TTypecomptime

Returns: comptime(Layout)

Constants

GlobalAllocator constant module (malloc : fn(size : usize) -> ?(*(void)), calloc : fn(nmemb : usize, size : usize) -> ?(*(void)), realloc : fn(ptr : ?(*(void)), size : usize) -> ?(*(void)), free : fn(ptr : ?(*(void))) -> unit, aligned_alloc : fn(alignment : usize, size : usize) -> ?(*(void)), aligned_free : fn(ptr : ?(*(void))) -> unit)

The process-wide global allocator (mimalloc by default, falls back to libc).

Two allocation families live here and they are not interchangeable:

allocate with release with
malloc / calloc / realloc free
aligned_alloc aligned_free

Crossing the two corrupts the heap on Windows, where the aligned family is the CRT's separate _aligned_malloc / _aligned_free pair.

Under --allocator fixed there is ONE family: aligned_free and free are the same function, so the split above cannot bite (the region's aligned_alloc splits a misaligned front piece back into the pool and every release path coalesces through the same TLSF free).

Value: source_namespace_yo_id_7098(malloc: <unknown: fn(size : usize) -> ?(*(void))>, calloc: <unknown: fn(nmemb : usize, size : usize) -> ?(*(void))>, realloc: <unknown: fn(ptr : ?(*(void)), size : usize) -> ?(*(void))>, free: <unknown: fn(ptr : ?(*(void))) -> unit>, aligned_alloc: <fn(alignment, size)>, aligned_free: <unknown: fn(ptr : ?(*(void))) -> unit>)