ring-alloc

Ring-based memory allocator for Rust to use for short-living allocations.

Provides better flexibility compared to arena-based allocators since there's no lifetime bounds. However user should still deallocate memory in short time to avoid wasting memory.

Allocator uses ring buffer of chunks to allocate memory in front chunk, moving it to back when full. If next chunk is still occupied by old allocations, allocator will allocate new chunk. When there's enough chunks so that next chunk is always unoccupied, when first chunk becomes exhausted, it won't allocate new chunks anymore.

Failing to deallocate single block of memory will stop ring-allocator from reusing chunks, so be careful to not leak blocks or keep them alive for too long.

Usage

This crate provides two types of ring-allocators. RingAlloc is a thread-local allocator that owns its rings of chunks and uses user-provided underlying allocator to allocate chunks. RingAlloc is cheaply clonnable and clones share internal state.

#![cfg_attr(feature = "nightly", feature(allocator_api))]
use ring_alloc::RingAlloc;
use allocator_api2::{boxed::Box, vec::Vec};

fn foo() -> Vec<Box<u32, RingAlloc>, RingAlloc> {
    let alloc = RingAlloc::new();
    let b = Box::new_in(42, alloc.clone());

    let mut v = Vec::new_in(alloc);
    v.push(b);
    v
}

fn main() {
    let v = foo();
    assert_eq!(*v[0], 42);
}

OneRingAlloc is ZST allocator that uses global-state and thread-local storage. It can be used across threads and may transfer chunks between threads when thread exists with chunks that are still in use.

OneRingAlloc always uses global allocator to allocate chunks.

#![cfg_attr(feature = "nightly", feature(allocator_api))]
use ring_alloc::OneRingAlloc;
use allocator_api2::{boxed::Box, vec::Vec};

fn foo() -> Vec<Box<u32, OneRingAlloc>, OneRingAlloc> {
    let b = Box::new_in(42, OneRingAlloc);

    let mut v = Vec::new_in(OneRingAlloc);
    v.push(b);
    v
}

fn main() {
    let v = std::thread::spawn(foo).join().unwrap();
    assert_eq!(*v[0], 42);
}

Allocators are usable on stable Rust with allocator-api2 crate. "nightly" feature enables support for unstable Rust allocator_api, available on nightly compiler.

Benchmarks

warm-up

allocation

vec

Made with criterion-table

Conclusion

RingAlloc is faster than bumpalo in most cases. OneRingAlloc is slower than RingAlloc and bumpalo in exchange for multi-threading support.

Global allocator shows better results on reserve_exact(1) tests because it provides optimized Allocator::grow, not yet implemented in RingAlloc. Global allocator is slightly better on push for large vector. RingAlloc directs large allocations to underlying allocator, which is Global in tests.

License

Licensed under either of

• Apache License, Version 2.0, (license/APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (license/MIT or http://opensource.org/licenses/MIT)

at your option.

Contributions

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