Asignación estática y dinámica

01 · El menú completo

Tres maneras de obtener memoria

En el tema 29 vimos dónde queda cada cosa. Ahora miramos cómo se obtiene. Un programa en C tiene exactamente tres formas de conseguir un lugar donde guardar datos, y cada una tiene un momento distinto en que se decide el tamaño y se puede fallar:

La tabla ya dice casi todo. La asignación estática tiene una propiedad extraordinaria: si el programa enlaza, la memoria está garantizada para siempre. No hay un caso raro en que «no queden» esos bytes. En cambio, la asignación dinámica traslada el problema de «¿alcanza la memoria?» del momento de compilar al de ejecutar, y ahí hay que responderlo con cada llamada, para cada combinación de situaciones posibles, durante años. Un sistema embebido típico no tiene a nadie delante para reiniciarlo cuando falla.

02 · Los cargos contra malloc

Qué tiene de malo malloc

No es que malloc «no ande»: anda perfectamente en el escritorio. Es que en un microcontrolador chocan seis propiedades suyas con los requisitos del tema 2:

Estos problemas no son teóricos: son la razón por la que los estándares de programación para sistemas críticos los restringen. La regla 21.3 de MISRA C:2012 prohíbe usar las funciones de reserva y liberación de stdlib.h; la regla 3 de la guía «Power of 10» de la NASA/JPL exige no asignar memoria dinámicamente después de la inicialización. No son caprichos de la normativa: resumen décadas de fallos en el campo.

Ninguno de estos seis problemas aparece con una prueba de diez minutos en la mesa. La fragmentación y las fugas son fallos de acumulación: el sistema funciona perfectamente durante días o meses y después deja de hacerlo, y el cliente es quien lo descubre. Por eso no alcanza con «probé y andaba».

03 · El problema más traicionero

La fragmentación

La fragmentación es la situación en la que hay memoria libre suficiente, pero repartida en trozos demasiado chicos para atender un pedido. Se distinguen dos tipos:

• Fragmentación externa: el espacio libre está dividido en huecos separados por bloques en uso. Es la que sorprende, y la que ilustra el diagrama de abajo.
• Fragmentación interna: el bloque entregado es más grande que lo pedido (por la alineación, la cabecera o porque el pool tiene bloques fijos), y el sobrante se desperdicia dentro del bloque.

Lo importante de la figura es lo que no se ve en ninguna medición del sistema: hay 256 bytes libres, la mitad de la memoria, y un pedido de 112 falla. Quien mira el mallinfo o el contador de memoria libre ve «256 B libres» y no encuentra el problema. Para medirlo hay que mirar el mayor hueco, que casi ninguna biblioteca informa, y por eso la fragmentación se estudia con pruebas y simulaciones largas, como hace el programa de Python de este tema.

La fragmentación empeora con tres factores: tamaños muy variados (los bloques chicos quedan encajados entre los grandes), duraciones de vida distintas (los bloques de larga vida quedan como columnas en medio del heap) y mucho tiempo de funcionamiento (hay más oportunidades de que se acomoden mal). Y mejora con la unión de huecos vecinos al liberar (coalescing): si dos bloques adyacentes quedan libres, se funden en uno más grande. Pero esa unión solo ayuda cuando los vecinos se liberan, y en el ejemplo de arriba ningún vecino lo está.

Un detalle más que desmiente la intuición: las pruebas de rutina no la encuentran. En un programa que reserva y libera siempre en el mismo orden (como un ejemplo de manual) la fragmentación nunca aparece. Surge cuando el orden de liberación se vuelve impredecible, lo que sucede en producción, con eventos reales, y casi nunca en el laboratorio.

04 · La opción por defecto

Asignación estática bien hecha

La alternativa a malloc es declarar todo con tamaño fijo, decidido al diseñar. Suena rígido, pero en la práctica casi todo en un sistema embebido tiene una cota natural: el número de sensores es fijo, el mensaje más largo de un protocolo está definido, la cola de eventos tiene un tamaño máximo. La clave es hacer esa decisión explícita, centralizada y verificable:

/* config.h: TODOS los límites en un solo lugar, cada uno con su razón */
#define MAX_SENSORES        8        /* los de la placa: 8 canales del conversor          */
#define LARGO_MENSAJE       64       /* el mensaje más largo del protocolo (tema 41)       */
#define PROFUNDIDAD_COLA    16       /* eventos pendientes en el peor caso (tema 26)       */

/* sensores.c */
typedef struct { uint16_t crudo; int16_t calibrado; uint8_t estado; } Sensor;
static Sensor sensores[MAX_SENSORES];                       /* reserva estática: 8 x 6 = 48 bytes, en .bss */

/* El compilador verifica el presupuesto: si alguien agranda Sensor o MAX_SENSORES, no compila */
_Static_assert(sizeof(sensores) <= 128, "los sensores no deben pasar de 128 bytes de RAM");

Sensor *sensor_obtener(uint8_t i) {
    return (i < MAX_SENSORES) ? &sensores[i] : NULL;       /* el límite se comprueba explícitamente */
}

Cuatro ventajas se acumulan, y por eso es la opción por defecto en los sistemas embebidos serios:

• Se ve en el mapa. Cada byte reservado aparece en size y en el .map (tema 29). El presupuesto de RAM se puede auditar sin ejecutar nada.
• Cuesta cero en ejecución. No hay búsqueda ni cabecera: la dirección es una constante del enlazador.
• Falla en el momento correcto. Si no entra, falla el enlace, que es cuando el desarrollador puede reaccionar.
• Los límites quedan escritos. «Hasta 8 sensores» es una decisión de diseño, visible, discutible y probable; con malloc el límite real es «lo que alcance», y nadie sabe cuánto es.

El costo es que se reserva el máximo aunque no se use. Si el equipo solo suele tener 3 sensores conectados pero puede tener 8, los 5 restantes ocupan RAM de todos modos. Esa es una decisión consciente: con RAM de sobra es una pérdida aceptable; con RAM ajustada, se evalúa si algún límite puede bajarse, o si conviene un pool compartido (el apartado siguiente).

Dos hábitos más. Primero, validar los límites en cada entrada: un índice que viene de un mensaje externo se compara con el máximo antes de usarse, porque con arreglos estáticos un índice fuera de rango no «falla»: pisa lo que haya al lado (tema 31). Segundo, declarar los búferes grandes static a nivel de archivo, no como variables locales: un arreglo local de 512 bytes consume pila (y puede desbordarla), mientras que uno estático vive en .bss, donde el enlazador lo cuenta.

05 · Dinámica, pero sin sorpresas

Pools de bloques fijos

A veces el número de objetos vivos varía en ejecución: mensajes en tránsito, conexiones abiertas, eventos con datos. No se sabe cuántos habrá a la vez, pero sí un máximo, y los objetos tienen el mismo tamaño. Para eso existe el pool de memoria (memory pool): una reserva estática dividida en bloques de tamaño fijo, que se entregan y se devuelven uno por uno.

Resuelve casi todos los problemas de malloc de un golpe. Como todos los bloques son iguales, cualquier bloque libre sirve para cualquier pedido: no hay búsqueda, no hay fragmentación externa y el tiempo es constante. La implementación usa una lista de bloques libres en la que el enlace se guarda dentro del propio bloque libre (un bloque libre no guarda datos, así que su memoria sirve para guardar el puntero al siguiente), de modo que no hace falta ninguna estructura extra:

/* pool.h / pool.c: bloques de tamaño fijo, reservar y liberar en tiempo constante */
typedef struct {
    uint8_t *memoria;          /* el área, reservada estáticamente                              */
    size_t   tam_bloque;       /* múltiplo de 8, y al menos sizeof(void *)                      */
    size_t   cantidad;
    void    *libres;           /* cabeza de la lista de bloques libres                          */
    size_t   en_uso, maximo;   /* para medir: cuántos hay en uso, y el máximo alcanzado         */
} Pool;

void pool_iniciar(Pool *p, void *area, size_t tam_bloque, size_t cantidad) {
    p->memoria = area;  p->tam_bloque = tam_bloque;  p->cantidad = cantidad;
    p->libres = NULL;   p->en_uso = p->maximo = 0;
    for (size_t i = cantidad; i > 0; i--) {                /* encadena todos los bloques libres */
        void *bloque = p->memoria + (i - 1) * tam_bloque;
        *(void **)bloque = p->libres;                      /* el primer campo del bloque libre apunta al siguiente */
        p->libres = bloque;
    }
}

void *pool_reservar(Pool *p) {
    uint32_t pm = __get_PRIMASK();  __disable_irq();        /* sección crítica corta (tema 16) */
    void *bloque = p->libres;
    if (bloque != NULL) {
        p->libres = *(void **)bloque;                        /* sacar el primero de la lista */
        if (++p->en_uso > p->maximo) p->maximo = p->en_uso;
    }
    __set_PRIMASK(pm);
    return bloque;                                          /* NULL si el pool está vacío: falla clara y predecible */
}

bool pool_liberar(Pool *p, void *bloque) {
    uintptr_t desplazamiento = (uintptr_t)bloque - (uintptr_t)p->memoria;
    if (desplazamiento >= p->cantidad * p->tam_bloque || desplazamiento % p->tam_bloque != 0)
        return false;                                       /* no es un bloque de este pool: se rechaza */
    uint32_t pm = __get_PRIMASK();  __disable_irq();
    *(void **)bloque = p->libres;                            /* volver a ponerlo al frente de la lista */
    p->libres = bloque;
    p->en_uso--;
    __set_PRIMASK(pm);
    return true;
}

/* Uso: 16 mensajes de 32 bytes, todo reservado estáticamente */
static uint8_t area_mensajes[16 * 32] __attribute__((aligned(8)));
static Pool    pool_mensajes;
/* en la inicialización: pool_iniciar(&pool_mensajes, area_mensajes, 32, 16); */

Las dos operaciones son unas pocas instrucciones sin bucles: el tiempo es el mismo con el pool vacío, medio lleno o casi agotado, y se puede usar dentro de una interrupción (la sección crítica dura tres instrucciones). El campo maximo es oro para el diseño: al final de las pruebas en el peor caso, dice cuántos bloques se usaron realmente como máximo, y permite ajustar la cantidad con datos. Y el fallo, cuando ocurre, es claro e inmediato: pool_reservar devuelve NULL porque no quedan bloques, y no porque «hay memoria pero no junta».

El pool tiene dos costos honestos que hay que dimensionar:

• Fragmentación interna: cada objeto ocupa un bloque entero. Si los mensajes miden entre 16 y 64 bytes y el bloque es de 64, un mensaje de 16 desperdicia 48. Si los tamaños son muy variados, se usan varios pools con bloques de distinto tamaño (por ejemplo 32, 128 y 512 bytes) y cada pedido va al más chico que lo contenga.
• Hay que dimensionarlo para el peor caso. Como cada pool tiene su cantidad fija, si un tipo de pedido se agota, falla aunque los otros pools estén vacíos. La Parte 2 del programa de Python lo muestra con números.

Una regla de propiedad que ahorra errores: todo bloque tiene un dueño que es quien lo libera. Si un productor reserva un bloque y se lo pasa a una cola (tema 26), el consumidor es quien lo libera; esa regla se escribe en el diseño y se respeta siempre. Con las reglas escritas, los dos errores clásicos (fuga y doble liberación) se vuelven visibles en una revisión.

06 · El caso de los flujos de datos

Buffers circulares

Cuando lo que se mueve es un flujo (los bytes de una UART, las muestras de un conversor, las líneas de un registro) en lugar de objetos discretos, la estructura natural es el buffer circular (ring buffer): un arreglo de tamaño fijo con dos índices, uno donde se escribe y otro donde se lee, que dan la vuelta al llegar al final. El tema 16 lo usó para pasar datos de una ISR al programa principal sin pérdida; acá lo vemos desde el lado de la memoria: cómo se dimensiona y qué se decide cuando se llena.

#define RB_TAM  128                          /* POTENCIA de dos: el módulo se hace con una máscara, sin dividir */

typedef struct {
    uint8_t           datos[RB_TAM];
    volatile uint16_t cabeza;                /* cuántos bytes se escribieron en total (solo escribe el productor) */
    volatile uint16_t cola;                  /* cuántos bytes se leyeron en total   (solo escribe el consumidor) */
    uint16_t          perdidos;              /* cuántos datos se descartaron por falta de lugar */
} RingBuffer;

static inline bool rb_poner(RingBuffer *r, uint8_t b) {
    if ((uint16_t)(r->cabeza - r->cola) == RB_TAM) { r->perdidos++; return false; }   /* lleno: se descarta el NUEVO y se cuenta */
    r->datos[r->cabeza & (RB_TAM - 1)] = b;
    r->cabeza++;
    return true;
}

static inline bool rb_sacar(RingBuffer *r, uint8_t *b) {
    if (r->cabeza == r->cola) return false;                                       /* vacío */
    *b = r->datos[r->cola & (RB_TAM - 1)];
    r->cola++;
    return true;
}

Dos trucos de este código valen la pena. Los índices cabeza y cola no se reducen al tamaño: cuentan bytes totales y se enmascaran solo al indexar. Así, «lleno» es cabeza − cola == RB_TAM y «vacío» es cabeza == cola, sin desperdiciar una posición para distinguirlos y sin ambigüedad (funciona aunque los contadores de 16 bits den la vuelta, porque el tamaño es una potencia de dos). Y como cada índice lo escribe un solo lado, no hace falta ninguna sección crítica entre una ISR productora y un programa principal consumidor (el tema 16 explica por qué).

Cuánto tiene que medir

El tamaño del buffer sale de una cuenta, no de una corazonada: cuántos datos llegan mientras el consumidor no puede atenderlos. Con una UART a 115 200 baudios, cada byte ocupa 10 bits (inicio, 8 de datos y parada), o sea 11 520 bytes por segundo. Si el programa principal puede tardar hasta 5 ms en volver a leer, llegan 11 520 × 0,005 = 57,6 bytes: hace falta un mínimo de 58, y con margen y potencia de dos, 128. Pero si algún día una operación bloquea 50 ms (un borrado de flash, tema 28), llegarían 576 bytes y el buffer de 128 se desbordaría. El tamaño se calcula con el peor tiempo de respuesta del consumidor, no con el promedio.

Qué hacer cuando se llena

Un buffer que se llena obliga a elegir una política, y debe ser una decisión de diseño explícita, no un accidente:

Sobrescribir el dato más viejo parece una sutileza, pero cambia quién escribe cada índice: el productor tendría que mover la cola (que es del consumidor), y hace falta proteger el cambio con una sección crítica o diseñar el buffer para un único contexto. Por eso la política por defecto para flujos entre una ISR y el programa principal es descartar lo nuevo y contarlo.

07 · Un término medio muy usado

Arenas: reservar al arrancar y no liberar

Existe una forma de asignación dinámica casi tan segura como la estática: la arena (arena o bump allocator). Es un área estática con un único puntero que avanza: cada pedido se atiende moviendo el puntero, y nunca se libera nada individualmente. Sirve para objetos cuya cantidad se conoce recién al arrancar (por ejemplo, según la configuración leída o el hardware detectado) pero que viven hasta el apagado:

static uint8_t arena[2048] __attribute__((aligned(8)));
static size_t  usado;
static bool    cerrada;

void *arena_reservar(size_t n) {
    if (cerrada) return NULL;                       /* terminada la inicialización, no se reserva más */
    n = (n + 7u) & ~7u;                             /* alineación a 8 bytes */
    if (usado + n > sizeof arena) return NULL;
    void *p = &arena[usado];
    usado += n;
    return p;
}

void arena_cerrar(void) { cerrada = true; }         /* se llama al final de la inicialización */
size_t arena_usada(void) { return usado; }          /* para medir el presupuesto real */

/* main(): reservar según la configuración, cerrar la arena y entrar al bucle principal */

La reserva es de tiempo constante y no hay fragmentación, porque nada se libera. Y el patrón «reservar al inicio, nunca liberar, cerrar» acerca el comportamiento al de la asignación estática: si el sistema arranca, la memoria está reservada para siempre, y el único fallo posible ocurre en el arranque, cuando es fácil de detectar. Es el patrón al que apuntan las normas que dicen «no asignar después de inicializar».

08 · Cuando no queda otra

Si hay que usar malloc

A veces no hay alternativa razonable: una biblioteca de terceros (una pila TCP/IP, un intérprete) que usa el heap, o un producto sin requisitos críticos donde la comodidad pesa más. Entonces se contiene el daño:

• Reservar en el arranque y no liberar (una arena disfrazada). Si se llama a malloc solo durante la inicialización, no hay fragmentación ni fugas durante el funcionamiento.
• Comprobar siempre el resultado. Cada malloc tiene un if (p == NULL) con un camino de recuperación probado (tema 39).
• Medir. Con newlib, mallinfo() informa cuánto heap se pidió al sistema y cuánto hay en uso; hay que registrar su evolución a lo largo de pruebas largas:

#include <malloc.h>

void heap_informe(void) {
    struct mallinfo mi = mallinfo();
    /* mi.arena   : bytes que el heap obtuvo del sistema (con _sbrk), el «tope» alcanzado   */
    /* mi.uordblks: bytes en bloques ocupados                                               */
    /* mi.fordblks: bytes en bloques libres DENTRO de lo obtenido (no dice cuán juntos están) */
    log_printf("heap: obtenido=%d en uso=%d libre=%d\n", mi.arena, mi.uordblks, mi.fordblks);
}

/* Si 'uordblks' crece sin parar con el equipo en régimen, hay una fuga.
   Si 'arena' crece mientras 'uordblks' se mantiene, hay fragmentación. */

• Interceptar las llamadas con -Wl,--wrap=malloc: el enlazador redirige cada llamada a malloc hacia __wrap_malloc, que se define para contar, registrar el tamaño y la dirección de quien llama, o directamente detener el programa en depuración. Permite descubrir quién usa el heap (una biblioteca puede hacerlo sin que se note).
• Proteger el acceso si hay un RTOS o interrupciones: en newlib, se implementan los ganchos __malloc_lock y __malloc_unlock; y nunca se llama a malloc desde una ISR.
• Evitar la fragmentación con tamaños previsibles: pedir siempre los mismos pocos tamaños, o reservar un único bloque grande en el arranque y repartirlo con un pool propio.

Los RTOS suelen traer su propio administrador de memoria, que conviene conocer porque determina el comportamiento de todo el sistema. FreeRTOS ofrece cinco implementaciones intercambiables del heap, de más simple a más completa:

Y FreeRTOS permite evitar el heap por completo con la creación estática de tareas, colas y semáforos (xTaskCreateStatic, xQueueCreateStatic, con configSUPPORT_STATIC_ALLOCATION): el programador entrega los búferes, que viven en .bss, y el kernel no pide memoria. Para firmware que debe ser predecible, es la forma recomendada. Las funciones xPortGetFreeHeapSize() y xPortGetMinimumEverFreeHeapSize() informan del heap libre actual y de su valor mínimo histórico, que es la cifra que importa: cuánto estuvo cerca de agotarse.

09 · Comprobar que funciona

Verificación y diagnóstico

10 · Analogía con programación

Probar el modelo en Python

El programa implementa un heap con cabecera de 8 bytes por bloque, alineación a 8, primer ajuste y unión de huecos vecinos, o sea el comportamiento típico de un malloc simple. Tiene tres partes: un caso armado a mano que reproduce el diagrama de fragmentación, una simulación larga (200 000 operaciones) que compara el heap con pools de bloques fijos, y el cálculo del tamaño de un buffer circular a partir de una velocidad y un tiempo de respuesta.

# Heap con malloc/free (primer ajuste, con cabecera por bloque) frente a pool de bloques fijos.
import random
CAB, ALIN = 8, 8                                   # bytes de cabecera por bloque y alineación

class Heap:
    def __init__(self, tam):
        self.bloques = [[0, tam, True]]            # [inicio, tamaño total, libre]
        self.max_visitados = 0
    def malloc(self, n):
        total = (n + CAB + ALIN - 1) // ALIN * ALIN
        for i, (ini, tam, libre) in enumerate(self.bloques):
            self.max_visitados = max(self.max_visitados, i + 1)
            if libre and tam >= total:             # primer ajuste: el primer hueco que alcance
                if tam - total >= 16:              # sobra bastante: se parte el bloque
                    self.bloques[i] = [ini, total, False]
                    self.bloques.insert(i + 1, [ini + total, tam - total, True])
                else:
                    self.bloques[i][2] = False
                return ini
        return None
    def free(self, ini):
        for i, b in enumerate(self.bloques):
            if b[0] == ini: b[2] = True; break
        j = 0
        while j < len(self.bloques) - 1:           # unir huecos vecinos
            if self.bloques[j][2] and self.bloques[j + 1][2]:
                self.bloques[j][1] += self.bloques.pop(j + 1)[1]
            else: j += 1
    def libre_total(self): return sum(b[1] for b in self.bloques if b[2])
    def mayor_hueco(self): return max([b[1] for b in self.bloques if b[2]] or [0])

print("Parte 1: la fragmentación en un caso armado a mano")
h = Heap(1024)
punteros = [h.malloc(100) for _ in range(9)]       # nueve bloques de 100 bytes (112 con cabecera y alineación)
for p in punteros[1:8:2]: h.free(p)               # se liberan los bloques 1, 3, 5 y 7
print(f"  tras liberar la mitad: libre total = {h.libre_total()} B, mayor hueco = {h.mayor_hueco()} B")
print(f"  fragmentación = 1 - mayor hueco / libre total = {1 - h.mayor_hueco() / h.libre_total():.0%}")
print(f"  malloc(200) -> {'FALLA' if h.malloc(200) is None else 'ok'}   (hay {h.libre_total()} B libres, pero ninguno junto)")
print(f"  malloc(100) -> {'FALLA' if h.malloc(100) is None else 'ok'}")

print()
print("Parte 2: 200 000 operaciones con mensajes de 16 a 512 bytes (memoria de 4096 B, hasta 12 mensajes vivos)")
TAMANOS = (16, 32, 64, 128, 256, 512)
CLASES = ((64, 16), (256, 6), (512, 3))            # pools: (tamaño de bloque, cantidad) = 1024 + 1536 + 1536 = 4096 B

def simular(usa_pool, semilla, ops=200_000, tam_mem=4096, max_vivos=12, clases=CLASES):
    rnd = random.Random(semilla)
    heap, vivos = Heap(tam_mem), []
    libres = {tam: cant for tam, cant in clases}
    pedidos = fallos_frag = fallos_lleno = 0
    for _ in range(ops):
        if vivos and (len(vivos) >= max_vivos or rnd.random() < 0.5):
            x = vivos.pop(rnd.randrange(len(vivos)))
            if usa_pool: libres[x] += 1
            else: heap.free(x)
            continue
        n = rnd.choice(TAMANOS)
        pedidos += 1
        if usa_pool:
            utiles = [tam for tam, _ in clases if tam >= n and libres[tam] > 0]
            clase = utiles[0] if utiles else None
            if clase is None: fallos_lleno += 1
            else: libres[clase] -= 1; vivos.append(clase)
        else:
            p = heap.malloc(n)
            if p is None:
                if heap.libre_total() >= n + CAB: fallos_frag += 1
                else: fallos_lleno += 1
            else: vivos.append(p)
    return pedidos, fallos_frag, fallos_lleno, heap.max_visitados

for etiqueta, pool in (("heap con malloc/free", False), ("3 pools de bloques fijos", True)):
    ped, ff, fl, visitas = simular(pool, 7)
    detalle = f"; bloques recorridos en el peor malloc: {visitas}" if not pool else "; el peor pedido recorre 3 clases como máximo"
    print(f"  {etiqueta:<25} pedidos {ped}: fallos con memoria suficiente (fragmentación) {ff}, fallos por falta real {fl}{detalle}")
ped, ff, fl, _ = simular(True, 7, clases=((512, 12),))
print(f"  1 pool de 12 bloques de 512 B ({12 * 512} B, para el peor caso): pedidos {ped}, fallos {ff + fl}: nunca falla, pero cuesta {12 * 512 - 4096} B más que el heap")

print()
print("Parte 3: tamaño de un buffer circular (UART a 115200 baudios, 10 bits por byte)")
def potencia_de_dos(n):
    p = 1
    while p < n: p *= 2
    return p
baudios, bits_por_byte, pausa_ms = 115200, 10, 5
bytes_por_s = baudios / bits_por_byte
llegan = bytes_por_s * pausa_ms / 1000
print(f"  llegan {bytes_por_s:.0f} B/s; en una pausa de {pausa_ms} ms del bucle principal llegan {llegan:.1f} B")
for margen in (1, 2, 4):
    minimo = int(llegan * margen) + 1
    print(f"  margen x{margen}: mínimo {minimo} B -> potencia de dos: {potencia_de_dos(minimo)} B")
pausa_ms = 50
llegan = bytes_por_s * pausa_ms / 1000
print(f"  si una pausa de {pausa_ms} ms es posible: llegan {llegan:.0f} B -> con margen x2: {potencia_de_dos(int(llegan * 2) + 1)} B")

Resultado, parte 1: nueve bloques de 100 bytes (112 con cabecera y alineación) llenan un heap de 1024 casi por completo (quedan 16 B al final); al liberar los bloques 1, 3, 5 y 7, el libre total es de 464 bytes y el mayor hueco de solo 112, una fragmentación del 76 %: malloc(200) falla con 464 bytes libres, y malloc(100) sí entra. Parte 2: con mensajes de 16 a 512 bytes y hasta 12 vivos en 4096 bytes, el heap tuvo 100 040 pedidos, de los cuales 74 fallaron aunque había memoria suficiente (fragmentación pura) y 4 por falta real, y el peor malloc recorrió 20 bloques antes de decidir; tres pools de bloques fijos (16 de 64 B, 6 de 256 B y 3 de 512 B, los mismos 4096 bytes) tuvieron cero fallos por fragmentación pero 1211 por falta de bloques de su clase, porque el reparto de tamaños no coincide con la demanda; un único pool de 12 bloques de 512 B (6144 bytes) nunca falla, pero cuesta 2048 bytes más que el heap. Parte 3: la UART a 115 200 baudios entrega 11 520 B/s, así que en una pausa de 5 ms llegan 57,6 B: un mínimo de 58, que con margen ×1, ×2 y ×4 da buffers de 64, 128 y 256 bytes; si una pausa de 50 ms es posible, llegan 576 B y con margen ×2 hacen falta 2048.

Lo que enseña esta salida es una compensación honesta: el heap aprovecha mejor la memoria pero falla de forma impredecible, y el pool falla de forma predecible pero exige dimensionarse para el peor caso, a veces con más memoria. Probá cambiar max_vivos a 8 (el heap casi no falla: 1 fallo en 100 002 pedidos) o a 16 (los fallos suben a 750 por fragmentación y 50 por falta real), o cambiar la composición de CLASES para ver cómo un pool bien ajustado a la demanda elimina los fallos.

11 · Exploración interactiva

Heap contra pool

El laboratorio es una memoria de 512 bytes que se puede administrar de dos maneras: como un heap (malloc/free con cabecera de 8 bytes, primer ajuste y unión de huecos) o como un pool de 8 bloques de 64 bytes. Reservá y liberá bloques y mirá cómo se reparte la memoria, cuánto queda libre en total, cuál es el mayor hueco y cuánto vale la fragmentación.

Recorrido guiado

1. Con el Heap, apretá «Llenar con 8 bloques de 56 B»: cada pedido de 56 bytes ocupa 64 con cabecera y alineación, y los ocho llenan los 512 B justos. Fijate en la cabecera: 8 bytes de cada 64 no son datos.
2. Apretá «Liberar los pares»: quedan 256 bytes libres, la mitad de la memoria, pero en cuatro huecos de 64. La fragmentación es del 75 %.
3. Elegí 100 bytes y apretá «Reservar»: el pedido necesita 112 bytes seguidos, y falla con 256 libres. Es exactamente el diagrama del apartado 3. Ahora elegí 24 bytes y reservá: ese sí entra, porque cabe en un hueco.
4. Liberá, con el selector, el bloque #3, que está flanqueado por los huecos de #2 y #4: los tres se unen en un solo hueco de 192 bytes. Probá otra vez los 100 bytes: ahora entra. La unión de huecos vecinos repara la fragmentación solo si los vecinos se liberan.
5. Cambiá a Pool y repetí los pasos 1 a 3: el pool llena 8 bloques con los mismos 56 bytes, se liberan los pares y el mayor hueco sigue siendo un bloque. Reservá 24 o 56 bytes: siempre entra, porque cualquier bloque libre sirve. La fragmentación externa es siempre cero.
6. En el pool, probá el pedido de 100 bytes: no entra en un bloque de 64, aunque haya bloques libres. Ese es el costo: el pool solo sirve para objetos que caben en su bloque, y cada objeto, por chico que sea, ocupa un bloque entero (un pedido de 16 desperdicia 48).

12 · Método de trabajo

Método: elegir cómo reservar

1. Por defecto, estático. Si el número de objetos tiene una cota natural y razonable, se declara un arreglo con ese máximo, con la constante en config.h, un _Static_assert del presupuesto y la validación de los índices.
2. Si el flujo es de bytes, buffer circular. Dimensionalo con la tasa de llegada y el peor tiempo de respuesta del consumidor, y elegí explícitamente qué se pierde cuando se llena. Contá los descartes.
3. Si son objetos de tamaño fijo que van y vienen, pool. Un bloque por objeto, con un dueño claro, dimensionado con el máximo de objetos simultáneos y verificado con el contador maximo.
4. Si los tamaños varían mucho, varios pools (uno por clase de tamaño), y una arena para lo que se decide al arrancar.
5. Asigná al arrancar, nunca después. Todo lo dinámico que sea posible, se reserva en la inicialización y no se libera. Cerrá la arena.
6. Si no hay manera de evitar malloc, contenelo: envolvelo con --wrap, chequeá cada resultado, medí con mallinfo o con las funciones de tu RTOS, y no lo llames desde una ISR.
7. Probá el camino de «sin memoria». Un pool agotado o un malloc que devuelve NULL no son errores de programación: son situaciones previstas, y su manejo se verifica forzándolas.
8. Medí en el tiempo. Los problemas de memoria dinámica son de acumulación: una prueba de horas o días con carga real vale más que cien pruebas de minutos.

13 · Comprensión

Confusiones frecuentes

14 · Práctica guiada

Ejercicios

1. Tamaño de un buffer circular

Una UART a 9600 baudios (10 bits por byte) alimenta un buffer circular. El programa principal puede tardar hasta 20 ms en volver a leerlo. ¿Cuántos bytes llegan en ese plazo? ¿Qué tamaño de buffer (potencia de dos, con margen ×2) elegirías?

2. El costo de la cabecera

Un sistema guarda 100 mensajes de 20 bytes. Con un heap que pone 8 bytes de cabecera y alinea a 8, ¿cuántos bytes ocupan en total? ¿Y con un pool de bloques de 24 bytes? ¿Cuánto se desperdicia en cada caso?

3. Dimensionar un pool

Un productor genera un mensaje cada 10 ms. El consumidor puede tardar hasta 80 ms en procesar y liberar cada uno. ¿Cuántos bloques hacen falta como mínimo? ¿Cuántos pondrías con un margen del 50 %? Si cada bloque mide 32 bytes, ¿cuánta RAM es?

4. Leer una fragmentación

Un heap tiene estos huecos libres: 112, 112, 112, 112 y 16 bytes. ¿Cuánto es el libre total, el mayor hueco y la fragmentación? ¿Entra un pedido de 100 bytes (112 con cabecera)? ¿Y uno de 120?

5. ¿Qué elegir?

Para cada caso, elegí entre asignación estática, pool, buffer circular y arena: (a) la tabla de 12 calibraciones de un instrumento, (b) los paquetes de red recibidos, cada uno de hasta 128 bytes, que van de la interrupción a una tarea, (c) las líneas de un registro de eventos que se quiere conservar en memoria, (d) los objetos de configuración, cuyo número se lee de la flash al arrancar y no cambia.

6. Qué se pierde

Un buffer circular de telemetría se llena cada vez que el enlace de radio se cae unos minutos. ¿Qué política elegirías: descartar el dato nuevo o sobrescribir el más viejo? ¿Cambiaría la respuesta si los datos fueran comandos de control en lugar de telemetría?

15 · Síntesis

Ideas para recordar

¿Listo para el tema siguiente?

Antes de avanzar, buscá un proyecto tuyo y respondé: ¿hay algún malloc o new? Si lo hay, ¿cuándo se llama (solo al arrancar o durante el funcionamiento)? ¿Se chequea el resultado? ¿Qué pasaría si un día devolviera NULL? Después elegí un flujo de datos (una UART, un sensor) y calculá el tamaño de su buffer con el peor tiempo de respuesta. Si podés responder con números, ya tenés criterio para decidir cómo se reserva cada byte de RAM.

En el próximo tema vemos qué ocurre cuando estas decisiones salen mal: los errores de memoria. Desbordamiento de pila y de buffers, punteros inválidos, la unidad de protección de memoria (MPU) y cómo detectarlos temprano.