Historia: La gestión de memoria de Rust evolucionó de una interfaz de asignador global única (GlobalAlloc, estabilizada en Rust 1.28) a un sistema más flexible y consciente de tipos (Allocator, actualmente inestable pero disponible en std::alloc). GlobalAlloc sirve como el puente de bajo nivel hacia los primitivos de memoria del sistema operativo (por ejemplo, malloc, VirtualAlloc), funcionando exclusivamente con punteros en bruto y tamaños en bytes sin información de tipo.
El problema surge porque GlobalAlloc expone la manipulación de memoria en bruto que el compilador no puede verificar. Los implementadores deben hacer cumplir manualmente invariantes críticos: garantías de alineación, emparejamiento de asignación/desasignación y la prohibición de liberaciones dobles. Debido a que GlobalAlloc sustenta Box, Vec y Rc, cualquier violación propaga comportamiento indefinido a lo largo de todo el programa, lo que exige el marcador unsafe impl para señalar que el programador asume la responsabilidad de estos contratos de seguridad.
La solución implica un estricto cumplimiento del contrato Layout. El método alloc debe devolver un puntero que satisfaga Layout::align(), y dealloc solo debe ser llamado con el diseño idéntico utilizado para la asignación. Además, el asignador debe garantizar que la memoria no sea recuperada mientras todavía está referenciada por abstracciones seguras. El rasgo Allocator mitiga estos riesgos al proporcionar una interfaz genérica y segura que maneja internamente los cálculos de Layout, delegando las operaciones inseguras a las implementaciones subyacentes de 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 equipo que desarrollaba un motor de comercio de alta frecuencia observó que el asignador de la biblioteca estándar introducía un jitters de latencia inaceptable debido a la contención de bloqueo en el montón global. Necesitaban un asignador de incremento personalizado pre-asignado desde una gran página para garantizar un acceso a memoria determinístico y local a NUMA para las actualizaciones del libro de órdenes en el camino caliente.
Se evaluaron varias soluciones. El primer enfoque consideró envolver el asignador del sistema con un grupo protegido por mutex, pero esto simplemente desplazó la contención y violó los requisitos de latencia. El segundo enfoque involucró el uso de la API Allocator inestable con Rust nocturno, creando una arena tipada para estructuras de orden específicas; sin embargo, esto requería una refactorización extensa de los usos de Vec y Box en todo el código y enfrentaba preocupaciones de estabilidad para el despliegue en producción.
La tercera solución, finalmente seleccionada, implementó GlobalAlloc para interceptar todas las asignaciones dinámicas dentro del hilo de comercio, dirigiéndolas a través de un asignador de incremento local a un hilo respaldado por regiones de mmap. Esta implementación requirió unsafe impl porque el asignador de incremento gestionaba punteros en bruto y tenía que garantizar que los punteros devueltos mantuvieran la alineación hasta límites de línea de caché de 64 bytes. El equipo eligió este camino porque proporcionaba intervención a nivel del sistema sin modificar los tipos de colección existentes, aunque exigía pruebas rigurosas con Miri para validar que el Layout pasado a dealloc siempre coincidiera con la asignación original. El resultado fue una reducción del 40% en la latencia p99, aunque el equipo mantuvo un protocolo de auditoría estricto para los bloques de código unsafe para prevenir fugas de memoria durante la volatilidad excepcional del mercado.
¿Por qué el Layout pasado a dealloc debe coincidir exactamente con el dado a alloc, y qué sucede si el tamaño difiere pero la alineación es correcta?
El contrato GlobalAlloc requiere identidad bit a bit entre el Layout utilizado para la asignación y la desasignación porque muchos asignadores (como jemalloc o dlmalloc) incrustan metadatos dentro del bloque asignado o mantienen listas segregadas por tamaño. Pasar un tamaño diferente, incluso uno más pequeño, hace que el asignador busque en el contenedor incorrecto o calcule un desplazamiento incorrecto para la coalescencia, lo que conduce a la corrupción del montón o vulnerabilidades de liberación doble. Esto difiere de free de C, que típicamente solo requiere el puntero, haciendo que el requisito de Rust sea más estricto pero necesario para la agnosticismo del asignador.
¿Cómo interactúa GlobalAlloc con Box::new cuando la caja es posteriormente eliminada, y por qué implementar Drop para el asignador en sí es problemático?
Cuando se invoca Box::new, llama a GlobalAlloc::alloc a través del #[global_allocator] estático. Al eliminar la Box, el compilador inserta una llamada a GlobalAlloc::dealloc con el Layout del tipo calculado automáticamente. Los candidatos a menudo pasan por alto que la implementación de GlobalAlloc debe ser 'static y segura para hilos (implementando Sync), pero no debe mantener un estado que haga referencia a la memoria asignada que gestiona, ya que esto crea una dependencia circular donde eliminar el asignador requeriría acceder a sí mismo, potencialmente causando uso después de la liberación durante el desmantelamiento del programa.
¿Qué distingue los requisitos de seguridad de GlobalAlloc::alloc_zeroed de alloc, y por qué no puede la implementación simplemente llamar a alloc seguido de std::ptr::write_bytes?
Mientras alloc_zeroed podría teóricamente implementarse como alloc más la nulificación, la biblioteca estándar lo proporciona como un método distinto para permitir que los asignadores aprovechen optimizaciones de páginas en cero específicas del sistema operativo (por ejemplo, MAP_ANONYMOUS en Linux devuelve páginas pre-cero). Desde una perspectiva de seguridad, alloc_zeroed debe garantizar que la memoria devuelta contenga bytes cero, que es una condición de post-cierre más fuerte que alloc (que devuelve memoria no inicializada). Si una implementación afirma falsamente la nulificación pero devuelve basura, el código seguro que asume la inicialización cero (crítica para contextos sensibles a la seguridad) leería datos no inicializados, violando las garantías de seguridad de Rust.