pub struct Reservation { /* private fields */ }Expand description
An owning handle to one aligned span of anonymous virtual memory.
as_ptr() is non-null, aligned to the align requested at reservation, and
valid for len() bytes for the lifetime of this handle. The span is not
initialised. Dropping the handle returns the whole underlying OS reservation
to the OS exactly once.
For a self-hosted allocator that records (reservation, reservation_len) in
its own metadata rather than keeping a Vec<Reservation>, use
into_parts to take the raw reservation (suppressing the
Drop) and release it later with release.
Reservation is Send (the span is owned exclusively) but not Sync
(writes through the raw pointer are unsynchronised — that is the caller’s
concern).
Implementations§
Source§impl Reservation
impl Reservation
Sourcepub fn as_ptr(&self) -> *mut u8
pub fn as_ptr(&self) -> *mut u8
The aligned usable base of this span. Non-null, valid for len
bytes, aligned to the align requested at reservation time.
Sourcepub const fn is_empty(&self) -> bool
pub const fn is_empty(&self) -> bool
Whether the usable span is empty (always false — reserve_aligned
rejects zero sizes; provided for lint-friendliness).
Sourcepub fn reservation_ptr(&self) -> *mut u8
pub fn reservation_ptr(&self) -> *mut u8
The start of the underlying OS reservation (may sit below
as_ptr due to the over-reserve + trim technique).
Sourcepub const fn reservation_len(&self) -> usize
pub const fn reservation_len(&self) -> usize
The full size of the underlying OS reservation.
Sourcepub fn into_parts(self) -> (*mut u8, usize, usize)
pub fn into_parts(self) -> (*mut u8, usize, usize)
Consume the handle WITHOUT releasing the OS reservation, returning the
(reservation_ptr, reservation_len, align) the caller must later hand to
release exactly once. Use this when your allocator records the
reservation in its own self-hosted metadata instead of relying on
Drop.
align is the alignment originally requested; the native release paths
ignore it, but it is required for the miri fallback to reconstruct the
exact Layout. A self-hosting allocator that always uses one alignment
can pass that constant to release instead of storing this value.
Sourcepub unsafe fn from_raw_parts(
base: *mut u8,
len: usize,
reservation: *mut u8,
reservation_len: usize,
align: usize,
) -> Self
pub unsafe fn from_raw_parts( base: *mut u8, len: usize, reservation: *mut u8, reservation_len: usize, align: usize, ) -> Self
Wrap a pre-existing OS reservation (e.g. one obtained from
VirtualAllocExNuma or another platform-specific allocator that
reserve_aligned does not call directly) in a Reservation handle.
The handle then participates in the normal RAII lifecycle: on Drop
(or via release) the underlying reservation is returned to the OS
using the platform-appropriate release routine
(VirtualFree(MEM_RELEASE) on Windows, munmap on Unix,
std::alloc::dealloc on miri).
This is the inverse of into_parts and exists for
the cross-crate handoff pattern: a sibling crate (numa-shim on
Windows) issues a platform-specific reservation call that aligned-vmem
itself does not wrap, then adopts the result via this constructor so
downstream code can hold a uniform Reservation regardless of which
syscall produced it.
§Safety
All five values must describe a live, exclusively-owned OS
reservation compatible with aligned-vmem’s release path:
baseis the aligned usable start; non-null, valid forlenbytes, aligned toalign.lenis the usable span size, a non-zero multiple ofPAGE.reservationis the underlying OS reservation start (often equal tobase, but may be lower under the over-reserve + trim technique).reservation_lenis the full size of the OS reservation, a non-zero multiple ofPAGE,reservation_len >= len + (base - reservation).alignis a power of two>= PAGEand matches the alignment the OS reservation was created with. The native release paths (VirtualFree/munmap) ignore it; the miri fallback uses it to reconstruct the exactLayout.
The reservation must be released exactly once — by dropping this
handle, or by extracting via into_parts and calling release
manually. Constructing two Reservation handles over the same OS
reservation is undefined behaviour (double release).
On Windows specifically, the reservation MUST have been created with
MEM_RESERVE | MEM_COMMIT so VirtualFree(MEM_RELEASE) accepts it.
(VirtualAllocExNuma(..., MEM_RESERVE | MEM_COMMIT, ...) satisfies
this — that is the intended call site.)