3 stable releases
new 1.1.0 | Oct 20, 2024 |
---|---|
1.0.1 | Mar 21, 2024 |
1.0.0 | Sep 15, 2023 |
#126 in Memory management
392 downloads per month
31KB
432 lines
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)
at your option.
Contribution
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.
lib.rs
:
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.
Slabs
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.