Por qué malloc reserva más memoria de la que pides

Fuentes: Why malloc is doing more than I asked for

Un programador que pidió 13 bytes con malloc descubrió, mientras construía su propio asignador de memoria por curiosidad, que la reserva nunca coincide con lo solicitado. La respuesta está en los metadatos que el asignador guarda junto a cada bloque.

El artículo parte de un bump allocator, el diseño más simple posible: un cursor que avanza sobre un bloque de memoria预先 reservado. Es el más rápido, pero no permite liberar objetos individuales, lo que obliga a introducir información adicional en cada asignación.

El primer reto es reconstruir el tamaño del bloque a partir del puntero que recibe free(). La solución naïve es colocar una cabecera (Header) justo antes de la memoria de usuario y retroceder sizeof(Header) bytes. Sin embargo, el requisito de alineación introduce un acolchado variable entre la cabecera y el puntero, por lo que la distancia deja de ser fija. Para resolverlo se añade un puntero hacia atrás (back pointer) situado siempre a sizeof(void*) bytes antes de la memoria de usuario, independientemente del acolchado. La alineación se aplica al puntero que se devuelve al llamante, no al cursor del arena.

Esos bytes de acolchado desperdiciado constituyen fragmentación interna: pertenecen al bloque pero nadie los usa mientras dura la asignación. Para habilitar free() individual se sustituye el cursor por una lista libre (free list) enlazada, donde los bloques liberados se reinsertan para reutilización. El artículo describe la estrategia first-fit, que toma el primer bloque con tamaño suficiente, y deja para otra entrega técnicas más elaboradas como best-fit o listas segregadas por clases de tamaño.

El texto, escrito en estilo divulgativo y con fragmentos de código en C, sirve como introducción práctica a cómo funcionan internamente los asignadores de memoria en lenguajes sin recolección de basura.