Geschiedenis: Rust's geheugbeheer evolueerde van een enkele globale toewijzingsinterface (GlobalAlloc, gestabiliseerd in Rust 1.28) naar een flexibelere, type-bewuste systeem (Allocator, momenteel onstabiel maar beschikbaar in std::alloc). GlobalAlloc dient als de laagdrempelige schakel naar de geheugensystemen van het besturingssysteem (bijv. malloc, VirtualAlloc), die uitsluitend werken met ruwe pointers en byte-groottes zonder type-informatie.
Het probleem ontstaat omdat GlobalAlloc ruwe geheugensmanipulatie blootstelt die de compiler niet kan verifiëren. Implementatoren moeten handmatig kritische invarianten handhaven: uitlijningsgaranties, toewijzing/deallocatie-paren, en het verbod op dubbele vrijgaven. Omdat GlobalAlloc de basis vormt voor Box, Vec en Rc, leidt elke schending tot niet-gedefinieerd gedrag in het gehele programma, wat een unsafe impl marker vereist om aan te geven dat de programmeur de verantwoordelijkheid voor deze veiligheidscontracten op zich neemt.
De oplossing houdt in dat er strikt wordt vastgehouden aan het Layout contract. De alloc-methode moet een pointer retourneren die voldoet aan Layout::align(), en dealloc mag alleen worden aangeroepen met dezelfde layout die voor toewijzing is gebruikt. Bovendien moet de allocator ervoor zorgen dat geheugen niet wordt teruggevorderd terwijl het nog wordt verwezen door veilige abstracties. De Allocator eigenschap mildert deze risico's door een veilige, generieke interface te bieden die de Layout-berekeningen intern afhandelt, de onveilige operaties delegerend aan onderliggende GlobalAlloc-implementaties.
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), };
Een team dat een hoogfrequent handelsengine ontwikkelde, merkte op dat de allocator van de standaardbibliotheek onacceptabele latentie-jitter introduceerde vanwege vergrendeling in de globale heap. Ze hadden een aangepaste bump-allocator nodig die was voorgeallocateerd vanuit een enorme pagina om een NUMA-lokale, deterministische geheugentoegang voor hot path order book-updates te waarborgen.
Er werden verschillende oplossingen geëvalueerd. De eerste aanpak overwoog de systeemallocator te verpakken met een mutex-beschermde pool, maar dit verschuift slechts de vergrendeling en schendt de latentie-eisen. De tweede aanpak omvatte het gebruik van de onstabiele Allocator API met nightly Rust, waarbij een getypte arena voor specifieke orderstructuren werd gemaakt; echter, dit vereiste uitgebreide refactoring van Vec en Box-gebruik in de codebase en stuitte op stabiliteitsproblemen voor productie-implementatie.
De derde oplossing, die uiteindelijk werd gekozen, implementeerde GlobalAlloc om alle dynamische toewijzingen binnen de handelsdraad te onderscheppen, waarbij ze via een draad-lokale bump-allocator werden geleid die werd ondersteund door mmap-gebieden. Deze implementatie vereiste unsafe impl omdat de bump-allocator ruwe pointers beheerde en moest waarborgen dat geretourneerde pointers uitlijning voor tot 64-byte cache-lijngrenzen handhaafden. Het team koos deze weg omdat het systeemwijde interventie bood zonder bestaande verzamelingstypes aan te passen, hoewel het strenge testen met Miri vereiste om te valideren dat de Layout die aan dealloc werd doorgegeven altijd overeenkwam met de oorspronkelijke toewijzing. Het resultaat was een vermindering van 40% in p99-latentie, hoewel het team een strikt auditprotocol voor de unsafe codeblokken handhaafde om geheugenlekken tijdens uitzonderlijke marktschommelingen te voorkomen.
Waarom moet de Layout die aan dealloc wordt doorgegeven exact overeenkomen met die welke aan alloc is gegeven, en wat gebeurt er als de grootte verschilt maar de uitlijning correct is?
Het GlobalAlloc contract vereist bitgewijze identiteit tussen de Layout die wordt gebruikt voor toewijzing en deallocatie omdat veel allocators (zoals jemalloc of dlmalloc) metadata binnen het toegewezen blok inbedden of grootte-gesegregeerde lijsten onderhouden. Het doorgeven van een andere grootte – zelfs een kleinere – veroorzaakt dat de allocator naar het verkeerde vak kijkt of een onjuiste offset berekent voor samenvoegen, wat leidt tot heap-corruptie of dubbele vrijgave kwetsbaarheden. Dit verschilt van C's free, dat typisch alleen de pointer vereist, wat de vereiste van Rust strenger maakt maar noodzakelijk is voor allocator-agnosticisme.
Hoe interacteert GlobalAlloc met Box::new wanneer de box later wordt weggegooid, en waarom is het problematisch om Drop voor de allocator zelf te implementeren?
Wanneer Box::new wordt aangeroepen, roept het GlobalAlloc::alloc aan via de #[global_allocator] statische. Bij het weggooien van de Box voegt de compiler een oproep in naar GlobalAlloc::dealloc met de type Layout die automatisch is berekend. Kandidaten missen vaak dat de GlobalAlloc implementatie zelf 'static en thread-veilige (implementatie van Sync) moet zijn, maar het mag geen staat bevatten die verwijst naar het toegewezen geheugen dat het beheert, omdat dit een circulaire afhankelijkheid creëert waarbij het weggooien van de allocator toegang vereist tot zichzelf, wat mogelijk gebruik-na-vrijgave tijdens het afbreken van het programma veroorzaakt.
Wat onderscheidt de veiligheidsvereisten van GlobalAlloc::alloc_zeroed van alloc, en waarom kan de implementatie niet simpelweg alloc aanroepen, gevolgd door std::ptr::write_bytes?
Hoewel alloc_zeroed theoretisch kan worden geïmplementeerd als alloc plus nullen, biedt de standaardbibliotheek het als een afzonderlijke methode om allocators in staat te stellen gebruik te maken van OS-specifieke nul-pagina optimalisaties (bijv. MAP_ANONYMOUS op Linux retourneert voor-geheugen pagina's). Vanuit een veiligheids perspectief moet alloc_zeroed garanderen dat het geretourneerde geheugen nul bytes bevat, wat een strengere post-voorwaarde is dan alloc (dat niet-geïnitialiseerd geheugen retourneert). Als een implementatie foutief nul-initiatie claimt maar rommel teruggeeft, zou veilige code die aanneemt dat nul-initialisatie plaatsvindt (kritisch voor veiligheidssensitive contexten) niet-geïnitialiseerde gegevens lezen, wat de veiligheidsgaranties van Rust zou schenden.