no_std y alloc: recuperar Box y Vec aportando tu propio allocator

Aquí se cierra el círculo de todo el nivel. En la primera lección viste que Box y Vec sacan su memoria del allocator global; ahora vas a ver qué ocurre cuando no hay sistema operativo debajo que provea ese allocator. Un microcontrolador, un kernel, un cargador de arranque: entornos #![no_std] donde no existe std porque no hay OS que dé hilos, ficheros ni un malloc de sistema. La pregunta es si en ese desierto pierdes Vec y String. La respuesta —y es una de las decisiones de diseño más elegantes de Rust— es que no: esas colecciones no viven en std ni en el lenguaje, sino en un crate intermedio llamado alloc, que funciona en cualquier parte a cambio de una sola cosa: que tú aportes un allocator global. Implementa GlobalAlloc sobre la RAM que tu hardware controla, y todo el ecosistema de colecciones de alto nivel se enciende sobre metal desnudo.

Tres capas: core, alloc, std

La biblioteca de Rust no es monolítica; está partida en tres crates apilados según lo que exigen del entorno:

• core es el corazón sin dependencias: tipos primitivos, Option, Result, iteradores, traits. No asigna memoria y no supone nada del entorno; funciona incluso sin heap. Todo programa Rust lo tiene, no_std incluido.
• alloc añade justo lo que necesita un heap: Box, Vec, String, Rc, Arc, BTreeMap. No supone un sistema operativo, pero sí exige un allocator global que le diga de dónde sacar y a dónde devolver memoria.
• std es core más alloc más todo lo que necesita un OS: hilos, ficheros, sockets, HashMap, y un allocator por defecto (System) ya montado sobre el malloc de la plataforma.

Un detalle revelador de dónde cae la frontera: BTreeMap vive en alloc, pero HashMap vive en std. La razón no es el heap —ambos asignan— sino que el HashMap estándar siembra su función de hash con aleatoriedad del sistema operativo para resistir ataques de colisiones, y esa entropía es un servicio del OS que alloc no puede asumir. La estratificación no separa por “qué tan avanzado” es el tipo, sino por qué capacidad exacta del entorno exige cada uno.

Un binario normal usa std y no piensa en esto. Un binario #![no_std] renuncia a std —porque no hay OS—, se queda con core gratis, y puede optar a alloc si acepta el trato: aportar el allocator que std le daba hecho.

flowchart TD
C[core sin heap ni OS siempre disponible] --> AL[alloc anade Box Vec String]
AL --> ST[std anade hilos ficheros y allocator System]
AL -.exige.-> G[tu implementacion de GlobalAlloc]
C -.base de.-> NS[binario no_std embebido o kernel]
NS -.puede optar a.-> AL
style C fill:#89b4fa,color:#11111b
style AL fill:#cba6f7,color:#11111b
style G fill:#f38ba8,color:#11111b
style ST fill:#a6e3a1,color:#11111b

Encender alloc en no_std

En un binario #![no_std], alloc no viene por defecto: hay que traerlo con extern crate alloc; y luego importar de él lo que uses. En cuanto haya un #[global_allocator] registrado, Box y Vec funcionan igual que en std:

#![no_std]
#![no_main]

extern crate alloc;                 // trae el crate alloc

use alloc::boxed::Box;
use alloc::vec::Vec;
use alloc::string::String;

fn construir() -> Vec<u32> {         // Vec en metal desnudo
    let mut v = Vec::new();
    v.push(1);
    v.push(2);
    let _b = Box::new(99u32);        // Box sobre tu propio heap
    v
}

Lo notable es que construir es idéntico al que escribirías en std. El crate alloc no sabe —ni le importa— si debajo hay un OS o un kernel que tú escribiste: solo sabe que existe un allocator global al que pedir. Toda la diferencia está en quién provee ese allocator.

Aportar el allocator sobre tu memoria

En un embebido o un kernel, tú posees una región de RAM y decides cómo repartirla. El allocator es la implementación de GlobalAlloc que la gestiona. En la práctica se usa un crate probado en vez de escribir el unsafe a mano; linked_list_allocator es el habitual:

use linked_list_allocator::LockedHeap;

#[global_allocator]
static HEAP: LockedHeap = LockedHeap::empty();

// En el arranque, cuando ya conoces la RAM libre (por el mapa del bootloader
// o el linker script), inicializas el heap con su base y su tamano:
unsafe fn init_heap(base: *mut u8, tam: usize) {
    unsafe { HEAP.lock().init(base, tam); }
}

El allocator arranca vacío y se inicializa cuando el hardware ya te dijo qué memoria hay libre. A partir de ese init, cada Box::new y cada Vec::push del programa tallan trozos de tu región. En un microcontrolador, embedded-alloc hace lo mismo sobre un [u8; N] estático reservado en RAM. La conexión con la lección 2 es directa: el allocator debe ser seguro entre hilos o interrupciones, de ahí el Locked que envuelve el heap.

El allocator entero, a mano

Para desmitificarlo del todo, aquí está un allocator global completo y autónomo: un bump —el de la lección anterior— sobre un array estático, sin dependencias ni OS. Solo asigna; nunca libera por objeto:

use core::alloc::{GlobalAlloc, Layout};
use core::cell::UnsafeCell;
use core::sync::atomic::{AtomicUsize, Ordering};

const TAM: usize = 64 * 1024;              // 64 KiB de heap, en la RAM del binario

struct BumpHeap {
    memoria: UnsafeCell<[u8; TAM]>,
    siguiente: AtomicUsize,               // desplazamiento del proximo hueco libre
}

unsafe impl Sync for BumpHeap {}          // afirmo que el acceso concurrente es seguro

unsafe impl GlobalAlloc for BumpHeap {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        let base = self.memoria.get() as usize;
        let mut actual = self.siguiente.load(Ordering::Relaxed);
        loop {
            let inicio = (base + actual + layout.align() - 1) & !(layout.align() - 1);
            let fin = inicio + layout.size();
            if fin > base + TAM {
                return core::ptr::null_mut();          // sin memoria: devuelve nulo
            }
            match self.siguiente.compare_exchange_weak(
                actual, fin - base, Ordering::Relaxed, Ordering::Relaxed,
            ) {
                Ok(_) => return inicio as *mut u8,
                Err(previo) => actual = previo,         // otro hilo gano: reintenta
            }
        }
    }
    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {}  // bump puro: no libera
}

#[global_allocator]
static HEAP: BumpHeap = BumpHeap {
    memoria: UnsafeCell::new([0; TAM]),
    siguiente: AtomicUsize::new(0),
};

Esas cuarenta líneas encienden Box, Vec y String en un binario sin sistema operativo. La unsafe impl Sync es la afirmación de la lección 37: prometo que el bucle de compare_exchange_weak hace segura la asignación concurrente. El dealloc vacío revela la naturaleza del bump: memoria que solo crece, adecuada para un firmware que asigna en el arranque y no vuelve a hacerlo. Cambia ese cuerpo por una free list y tendrás un allocator reutilizable; esa es, literalmente, la diferencia entre este juguete y linked_list_allocator.