Storia: La gestione della memoria in Rust è evoluta da un'interfaccia di allocatore globale unico (GlobalAlloc, stabilizzata in Rust 1.28) a un sistema più flessibile e consapevole dei tipi (Allocator, attualmente instabile ma disponibile in std::alloc). GlobalAlloc funge da ponte a basso livello con le primitive di memoria del sistema operativo (ad es. malloc, VirtualAlloc), operando esclusivamente su puntatori grezzi e dimensioni in byte senza informazioni sui tipi.
Il problema sorge perché GlobalAlloc espone la manipolazione di memoria grezza che il compilatore non può verificare. Gli implementatori devono far rispettare manualmente importanti invarianti: garanzie di allineamento, abbinamento tra allocazione/deallocazione e divieto di doppia liberazione. Poiché GlobalAlloc sostiene Box, Vec e Rc, qualsiasi violazione si propaga come comportamento indefinito nell'intero programma, necessitando il marcatore unsafe impl per segnalare che il programmatore si assume la responsabilità per questi contratti di sicurezza.
La soluzione implica una rigorosa aderenza al contratto di Layout. Il metodo alloc deve restituire un puntatore che soddisfi Layout::align(), e dealloc deve essere chiamato solo con il layout identico utilizzato per l'allocazione. Inoltre, l'allocatore deve garantire che la memoria non venga recuperata mentre è ancora referenziata da astrazioni sicure. Il tratto Allocator mitiga questi rischi fornendo un'interfaccia generica sicura che gestisce i calcoli di Layout internamente, delegando le operazioni non sicure alle implementazioni sottostanti di GlobalAlloc.
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), };
Un team che sviluppa un motore di trading ad alta frequenza ha osservato che l'allocatore della libreria standard introduceva una latenza inaccettabile a causa della contesa dei lock nel heap globale. Avevano bisogno di un allocatore bump personalizzato pre-allocato da una pagina enorme per garantire l'accesso alla memoria locale NUMA e deterministico per gli aggiornamenti dell'order book nel percorso caldo.
Sono state valutate diverse soluzioni. Il primo approccio ha considerato di incapsulare l'allocatore di sistema con un pool protetto da mutex, ma questo ha semplicemente spostato la contesa e violato i requisiti di latenza. Il secondo approccio ha coinvolto l'uso dell'API instabile Allocator con Rust notturno, creando un'arena tipizzata per strutture di ordine specifiche; tuttavia, questo richiedeva una vasta rifattorizzazione degli usi di Vec e Box nell'intera base di codice e affrontava preoccupazioni di stabilità per il deployment in produzione.
La terza soluzione, infine selezionata, ha implementato GlobalAlloc per intercettare tutte le allocazioni dinamiche all'interno del thread di trading, instradandole attraverso un allocatore bump locale al thread supportato da regioni mmap. Questa implementazione richiedeva unsafe impl perché l'allocatore bump gestiva puntatori grezzi e doveva garantire che i puntatori restituiti mantenessero l'allineamento fino ai confini della cache di 64 byte. Il team ha scelto questo percorso perché forniva un'intervenzione a livello di sistema senza modificare i tipi di raccolta esistenti, anche se richiedeva test rigorosi con Miri per convalidare che il Layout passato a dealloc corrispondesse sempre all'allocazione originale. Il risultato è stata una riduzione del 40% nella latenza p99, anche se il team ha mantenuto un rigoroso protocollo di audit per i blocchi di codice unsafe per prevenire perdite di memoria durante l'eccezionale volatilità del mercato.
Perché il Layout passato a dealloc deve corrispondere esattamente a quello fornito a alloc, e cosa succede se la dimensione differisce ma l'allineamento è corretto?
Il contratto di GlobalAlloc richiede identità bitwise tra il Layout utilizzato per l'allocazione e la deallocazione perché molti allocatori (come jemalloc o dlmalloc) incorporano metadati all'interno del blocco allocato o mantengono elenchi segregati per classi di dimensione. Passare una dimensione diversa—anche una più piccola—fa sì che l'allocatore cerchi nel bin sbagliato o calcoli un offset errato per la coalescenza, portando a corruzione dell'heap o vulnerabilità di doppia liberazione. Questo differisce da free in C, che richiede tipicamente solo il puntatore, rendendo il requisito di Rust più rigoroso ma necessario per l'agnosticismo degli allocatori.
Come interagisce GlobalAlloc con Box::new quando la box viene successivamente eliminata, e perché è problematico implementare Drop per l'allocatore stesso?
Quando viene invocato Box::new, chiama GlobalAlloc::alloc tramite la statica #[global_allocator]. Al momento dell'eliminazione del Box, il compilatore inserisce una chiamata a GlobalAlloc::dealloc con il Layout del tipo calcolato automaticamente. I candidati spesso perdono che l'implementazione di GlobalAlloc stessa deve essere 'static e thread-safe (implementando Sync), ma non deve mantenere uno stato che faccia riferimento alla memoria allocata che gestisce, poiché questo crea una dipendenza circolare in cui eliminare l'allocatore richiederebbe di accedere a se stesso, potenzialmente causando un uso dopo la liberazione durante il teardown del programma.
Cosa distingue i requisiti di sicurezza di GlobalAlloc::alloc_zeroed da alloc, e perché l'implementazione non può semplicemente chiamare alloc seguito da std::ptr::write_bytes?
Mentre alloc_zeroed potrebbe teoricamente essere implementato come alloc più lo zeroing, la libreria standard lo fornisce come metodo distinto per consentire agli allocatori di sfruttare ottimizzazioni specifiche del sistema operativo per le pagine azzerate (ad es. MAP_ANONYMOUS su Linux restituisce pagine già azzerate). Dal punto di vista della sicurezza, alloc_zeroed deve garantire che la memoria restituita contenga byte zero, che è una condizione posteriore più forte rispetto a alloc (che restituisce memoria non inizializzata). Se un'implementazione afferma falsamente di fare zeroing ma restituisce dati spazzatura, il codice sicuro che presume l'inizializzazione a zero (critica per contesti sensibili alla sicurezza) leggerebbe dati non inizializzati, violando le garanzie di sicurezza di Rust.