Los arena allocators en C eliminan las fugas de memoria y aceleran la asignación

Arena Allocators in C

Los arena allocators agrupan asignaciones con la misma vida útil en un solo bloque de memoria, evitando llamadas individuales a malloc y free. Elias Ebner explica cómo implementar uno en C: se reserva un chunk grande, se avanza un puntero con alineación de 8 bytes y se libera todo de una vez. El resultado es un código más rápido, versátil y con muchas menos fugas.

Cuando ya no necesitamos ninguno de los datos que viven dentro de ese gran bloque de memoria, podemos simplemente liberarlo todo de una vez (o, si queremos reutilizar esa misma memoria, reinicializar el arena a su estado inicial y comenzar a asignar desde el principio otra vez).
  1. duckqlz

    “Types.c” es código peligroso para llevar a cualquier proyecto.

    f32/64 hace suposiciones sobre la plataforma.

    Peor aún, las macros al final son funcionalmente incorrectas. Macros como MIN/MAX necesitan estar entre paréntesis para evitar errores de precedencia.

    Por ejemplo, tomamos `Min(x,y)` del código. Considera qué pasa si escribo

    `ans = 2 * Min(3,4)` porque tal como está definida Min, eso se expandirá a `ans = 2 * 3 < 4 ? 3 : 4` y aunque esperes que ans sea 3, en realidad se resolverá a 4.

    Errores sutiles como estos pueden colarse en el código y causar errores realmente difíciles de depurar.

    Por último, aunque u32 es un poco más rápido de escribir que `uint33_t`, hace que el proyecto sea más difícil de leer, forzando al lector a aprender el dialecto personal de C del autor. Aunque es una elección estilística, no veo por qué alguien querría sacrificar el resaltado de código y la expresividad por un poco menos de verbosidad

  2. teo_zero

    Ten en cuenta que la aritmética de punteros no está definida en punteros void *, aunque muchos compiladores lo permiten. Sería mejor que uses char * para "data".

    Además, tu código es propenso a desbordamiento cuando sumas data, used, alignment y size.

    Y por último, la función realloc podría reescribirse para no hacer nada si new_size es <= old_size.

  3. unwind

    Problemas más obvios con el código tal como se muestra:

    - Las macros que hacen aritmética (KiB, MIN, etc.) no ponen sus argumentos entre paréntesis, eso es muy peligroso.

    - El código asume que int e i32 tienen el mismo tamaño.

    - No hagas cast del valor de retorno de malloc(). Por favor, búscalo en Google.

    Aprecié el uso de structs por valor, es un buen diseño.

    Estoy de acuerdo en que hay riesgo de desbordamiento en la aritmética alrededor de tamaños/alineación, pero con un `usize` de 64 bits eso debería ser mayormente teórico.

Más de este día

2026-10-14