Escribir un allocator global que instrumenta y cuenta asignaciones

Como el allocator global es solo un trait, nada te impide escribir el tuyo. Pero rara vez querrás reimplementar malloc desde cero: el patrón valioso es envolver el allocator del sistema para observarlo. Un allocator que delega cada reserva en System y, de paso, suma bytes en un contador te da algo que ninguna librería externa puede darte con tanta precisión: la contabilidad exacta de toda la memoria que tu programa —y sus dependencias— pide al heap. Cuántos bytes hay vivos ahora, cuál fue el pico, cuántas asignaciones se han hecho. Escribirlo son veinte líneas; hacerlo correcto exige entender dos peligros que solo aparecen en este territorio: la reentrancia, porque tu código corre dentro del allocator, y las carreras de datos, porque corre en todos los hilos a la vez.

Envolver System y contar bytes

La idea es un tipo sin estado propio que reenvía todo a System y actualiza contadores globales antes o después de delegar:

use std::alloc::{GlobalAlloc, Layout, System};
use std::sync::atomic::{AtomicUsize, Ordering};

struct Contador;

static VIVOS: AtomicUsize = AtomicUsize::new(0);      // bytes asignados ahora mismo
static PICO: AtomicUsize = AtomicUsize::new(0);       // maximo historico
static ASIGNACIONES: AtomicUsize = AtomicUsize::new(0);

unsafe impl GlobalAlloc for Contador {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        let p = unsafe { System.alloc(layout) };      // delega en el sistema
        if !p.is_null() {
            let previo = VIVOS.fetch_add(layout.size(), Ordering::Relaxed);
            ASIGNACIONES.fetch_add(1, Ordering::Relaxed);
            PICO.fetch_max(previo + layout.size(), Ordering::Relaxed);
        }
        p
    }

    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        unsafe { System.dealloc(ptr, layout) };
        VIVOS.fetch_sub(layout.size(), Ordering::Relaxed);
    }
}

#[global_allocator]
static GLOBAL: Contador = Contador;

System es un tipo sin campos que ya implementa GlobalAlloc, así que System.alloc(layout) reenvía la petición al malloc de la plataforma. Nuestro papel se reduce a interponer los contadores. Fíjate en que solo sumamos si el puntero no es nulo: si el sistema no pudo asignar, no hay bytes que contabilizar.

La trampa de la reentrancia

Aquí está el error que casi todo el mundo comete la primera vez. Es tentador imprimir desde dentro del allocator para depurar:

unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
    println!("pido {} bytes", layout.size()); // PELIGRO: println puede asignar
    unsafe { System.alloc(layout) }
}

El problema es que println! formatea en un buffer que puede pedir memoria al heap, es decir, puede volver a llamar a tu alloc, que vuelve a println!, que vuelve a asignar… Es reentrancia: tu allocator se invoca a sí mismo, y en el mejor caso desbordas la pila; en el peor, corrompes tu propia contabilidad a mitad de una actualización. La regla de oro es tajante: dentro de alloc y dealloc no puedes hacer nada que asigne memoria. Nada de println!, nada de format!, nada de un Vec temporal. Solo aritmética, contadores atómicos y la delegación. Si necesitas emitir un diagnóstico, escribe a un buffer de tamaño fijo en la pila con write! sobre un [u8; N], o difiere el trabajo fuera del allocator.

realloc: la asignación que se contabiliza sola

Falta un cabo suelto. Un Vec que crece no llama a alloc, sino a realloc, y nosotros no la hemos implementado. ¿Se nos escapa de la cuenta? No, y la razón es sutil y elegante. Como no redefinimos realloc, entra en juego su implementación por defecto del trait, que está escrita en términos de self.alloc y self.dealloc —es decir, de nuestros métodos instrumentados—. Cada crecimiento de un Vec pasa así por nuestro alloc (suma la capacidad nueva) y nuestro dealloc (resta la vieja), y la contabilidad cuadra sin que escribamos una línea más.

Por qué basta Ordering::Relaxed

Los contadores usan Ordering::Relaxed, el orden de memoria más débil, y es la elección correcta. Relaxed garantiza que cada fetch_add es atómico —ningún incremento se pierde aunque mil hilos asignen a la vez— pero no impone ninguna relación de ordenación con otras variables. Y no la necesitamos: no estamos usando el contador como señal para sincronizar el acceso a otro dato, solo acumulamos una suma. Pedir SeqCst aquí sería pagar barreras de memoria caras en la ruta más caliente del programa —cada asignación— sin obtener nada a cambio. La lección general: elige el orden por lo que el contador significa, no por miedo; un acumulador estadístico es el ejemplo canónico de Relaxed legítimo.

flowchart TD
A[Vec pide memoria] --> B[Contador alloc]
B --> C[System alloc delega en malloc]
C --> D{puntero no nulo}
D -->|si| E[fetch_add en VIVOS y ASIGNACIONES]
E --> F[fetch_max actualiza PICO]
D -->|no| G[devuelve nulo sin contar]
F --> H[devuelve el puntero]
style B fill:#cba6f7,color:#11111b
style E fill:#89b4fa,color:#11111b
style H fill:#a6e3a1,color:#11111b

De las tres cifras, la más valiosa suele ser el pico, no los bytes vivos. Los bytes vivos fluctúan a cada instante y dicen poco por sí solos; el pico histórico, en cambio, es el que dimensiona tu heap: en un embebido te dice cuánta RAM debes reservar para que el programa nunca se quede sin memoria, y en un servidor revela el peor momento de presión aunque haya durado un milisegundo. Por eso lo actualizamos con fetch_max en cada alloc, capturando el máximo sin necesidad de muestrear. Esta métrica es justamente la que necesitarás en la última lección, cuando seas tú quien fije el tamaño del heap sobre metal desnudo.

Para leer las estadísticas desde el resto del programa basta una función que consulte los átomos, y esta sí puede asignar y formatear porque corre fuera del allocator:

fn estadisticas() -> (usize, usize, usize) {
    (
        VIVOS.load(Ordering::Relaxed),
        PICO.load(Ordering::Relaxed),
        ASIGNACIONES.load(Ordering::Relaxed),
    )
}