Onsen provides a hot Pool for objects. In most cases allocation from this Pool is faster and offers better locality than the standard allocator.
The first block in a Pool is size [Entry<T>; E]
, when a Pool runs out of storage it
allocates a new block from the system which is twice as big as the previous block. E should
be be optimized for the intended use. That is blocks should become close or equal to multiples
of cache lines, pages, huge pages, whatever makes most sense. There is a OptimalBlockSize
trait which does this calculations. Memory allocation happens only when necessary, creating a
pool is a cheap operation.
Onsen comes with its own Box and Rc/Weak implementations that wrap the underlying Pool in a safe way.
Allocating from a Pool returns Slot handles. These are lightweight abstractions to memory addresses, they do not keep a relation to the Pool they are allocated from. The rationale for this design is to make them usable in a VM that uses NaN tagging.
Because of this Slots need to be handled with care and certain contracts need to be enforced. The library provides some help to ensure correctness. The more expensive checks are only run in debug mode. Few things can not be asserted and are guarded by unsafe functions.
pool.leak()
which drops a pool while leaking its memory blocks. This can be
used when one will never try to free memory obtained from that Pool.&mut T
from a Slot is mutually exclusive to obtaining a Pin<&mut T>
.
slot.assume_init()
. This would break the Pin guarantees.
slot.get_uninit()
and slot.assume_init()
are
unsafe and must be enforced by the programmer.slot.into_u64()
, Slot::from_u64()
and Slot::from_u64_masked()
.