2 stable releases

1.0.1 Mar 21, 2024
1.0.0 Sep 15, 2023

#143 in Memory management

Download history 3/week @ 2024-02-29 17/week @ 2024-03-07 45/week @ 2024-03-14 198/week @ 2024-03-21 85/week @ 2024-03-28 58/week @ 2024-04-04 40/week @ 2024-04-11 27/week @ 2024-04-18 16/week @ 2024-04-25 6/week @ 2024-05-02 10/week @ 2024-05-09 10/week @ 2024-05-16 18/week @ 2024-05-23 51/week @ 2024-05-30 30/week @ 2024-06-06 52/week @ 2024-06-13

151 downloads per month


353 lines


Licensed under either of

at your option.


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual licensed as above, without any additional terms or conditions.


This allocator be straight up slabbin'.

A slab allocator is in theory the perfect one, if it's applicable. It's blazingly fast and avoids the issue of external fragmentation; but unlike the bump allocator it can free individual allocations, and unlike the stack allocator it can free them in an arbitrary order. The tradeoff here is that all allocations must have the same, fixed layout.

The allocator in this crate is totally unsafe, and meant specifically for use cases where stable addresses are required: when you allocate a slot, you get a pointer that stays valid until you deallocate it (or drop the allocator). Example use cases include linked structures or self-referential structures. If you don't have this requirement you may consider using slab or typed-arena for example as a safe alternative.


A slab is a pre-allocated contiguous chunk of memory containing slots. Each slot can either be free or occupied. A slab always starts out with all slots free, and new slots are given out on each allocation, until they run out, at which point a new slab is allocated. Slots that are deallocated are chained together in a linked list. Due to this, allocation amounts to 3 operations in the best case and ~8 in the worse case. Deallocation is always 3 operations.

No runtime deps