History: Rust's memory management evolved from a single global allocator interface (GlobalAlloc, stabilized in Rust 1.28) to a more flexible, type-aware system (Allocator, currently unstable but available in std::alloc). GlobalAlloc serves as the low-level bridge to the operating system's memory primitives (e.g., malloc, VirtualAlloc), operating exclusively on raw pointers and byte sizes without type information.
The problem arises because GlobalAlloc exposes raw memory manipulation that the compiler cannot verify. Implementors must manually enforce critical invariants: alignment guarantees, allocation/deallocation pairing, and the prohibition of double-frees. Because GlobalAlloc underpins Box, Vec, and Rc, any violation propagates undefined behavior throughout the entire program, necessitating the unsafe impl marker to signal that the programmer assumes responsibility for these safety contracts.
The solution involves strict adherence to the Layout contract. The alloc method must return a pointer satisfying Layout::align(), and dealloc must only be called with the identical layout used for allocation. Furthermore, the allocator must ensure memory is not reclaimed while still referenced by safe abstractions. The Allocator trait mitigates these risks by providing a safe, generic interface that handles Layout calculations internally, delegating the unsafe operations to underlying GlobalAlloc implementations.
use std::alloc::{GlobalAlloc, Layout, System}; use std::sync::atomic::{AtomicUsize, Ordering}; struct CountingAllocator { bytes_allocated: AtomicUsize, } unsafe impl GlobalAlloc for CountingAllocator { unsafe fn alloc(&self, layout: Layout) -> *mut u8 { let ptr = System.alloc(layout); if !ptr.is_null() { self.bytes_allocated.fetch_add(layout.size(), Ordering::SeqCst); } ptr } unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) { System.dealloc(ptr, layout); self.bytes_allocated.fetch_sub(layout.size(), Ordering::SeqCst); } } #[global_allocator] static GLOBAL: CountingAllocator = CountingAllocator { bytes_allocated: AtomicUsize::new(0), };
A team developing a high-frequency trading engine observed that the standard library's allocator introduced unacceptable latency jitter due to lock contention in the global heap. They required a custom bump allocator pre-allocated from a huge page to ensure NUMA-local, deterministic memory access for hot path order book updates.
Several solutions were evaluated. The first approach considered wrapping the system allocator with a mutex-protected pool, but this merely shifted contention and violated latency requirements. The second approach involved using the unstable Allocator API with nightly Rust, creating a typed arena for specific order structures; however, this required extensive refactoring of Vec and Box usages across the codebase and faced stability concerns for production deployment.
The third solution, ultimately selected, implemented GlobalAlloc to intercept all dynamic allocations within the trading thread, routing them through a thread-local bump allocator backed by mmap regions. This implementation required unsafe impl because the bump allocator managed raw pointers and had to guarantee that returned pointers maintained alignment for up to 64-byte cache line boundaries. The team chose this path because it provided system-wide intervention without modifying existing collection types, though it demanded rigorous testing with Miri to validate that the Layout passed to dealloc always matched the original allocation. The result was a 40% reduction in p99 latency, though the team maintained a strict audit protocol for the unsafe code blocks to prevent memory leaks during exceptional market volatility.
Why must the Layout passed to dealloc exactly match the one given to alloc, and what happens if the size differs but the alignment is correct?
The GlobalAlloc contract requires bitwise identity between the Layout used for allocation and deallocation because many allocators (like jemalloc or dlmalloc) embed metadata within the allocated block or maintain size-class segregated lists. Passing a different size—even a smaller one—causes the allocator to look in the wrong bin or calculate an incorrect offset for coalescing, leading to heap corruption or double-free vulnerabilities. This differs from C's free, which typically only requires the pointer, making Rust's requirement stricter but necessary for allocator agnosticism.
How does GlobalAlloc interact with Box::new when the box is later dropped, and why is implementing Drop for the allocator itself problematic?
When Box::new is invoked, it calls GlobalAlloc::alloc via the #[global_allocator] static. Upon dropping the Box, the compiler inserts a call to GlobalAlloc::dealloc with the type's Layout automatically computed. Candidates often miss that the GlobalAlloc implementation itself must be 'static and thread-safe (implementing Sync), but it must not hold state that references allocated memory it manages, as this creates a circular dependency where dropping the allocator would require accessing itself, potentially causing use-after-free during program teardown.
What distinguishes the safety requirements of GlobalAlloc::alloc_zeroed from alloc, and why can't the implementation simply call alloc followed by std::ptr::write_bytes?
While alloc_zeroed could theoretically be implemented as alloc plus zeroing, the standard library provides it as a distinct method to allow allocators to leverage OS-specific zeroed-page optimizations (e.g., MAP_ANONYMOUS on Linux returns pre-zeroed pages). From a safety perspective, alloc_zeroed must guarantee that the returned memory contains zero bytes, which is a stronger post-condition than alloc (which returns uninitialized memory). If an implementation falsely claims zeroing but returns garbage, safe code assuming zero-initialization (critical for security-sensitive contexts) would read uninitialized data, violating Rust's safety guarantees.