¿Qué tan grande puede ser un malloc en C?

Observaciones

Asumiendo un asignador típico, como el que usa glibc, hay algunas observaciones: {[18]]}

1. Ya sea que la memoria se use realmente o no, la región debe reservarse contiguamente en la memoria virtual.
2. Las regiones contiguas libres más grandes dependen del uso de memoria de las regiones de memoria existentes, y la disponibilidad de esas regiones para malloc.
3. Las prácticas de asignación dependen de la arquitectura y el sistema operativo. Además las llamadas al sistema subyacentes para obtener regiones de memoria se ven afectadas por estas prácticas (como malloc llamando a través de mmap para adquirir páginas).

Experimento

Aquí hay un programa simple para asignar el bloque más grande posible (compilar con gcc largest_malloc_size.c -Wall -O2:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static void *malloc_wrap(size_t size)
{
    void *p = malloc(size);
    if (p) {
        printf("Allocated %zu bytes from %p to %p\n", size, p, p + size);
    }
    else {
        printf("Failed to allocated %zu bytes\n", size);
    }
    return p;
}

int main()
{
    size_t step = 0x1000000;
    size_t size = step;
    size_t best = 0;
    while (step > 0)
    {
        void *p = malloc_wrap(size);
        if (p) {
            free(p);
            best = size;
        }
        else {
            step /= 0x10;
        }
        size += step;
    }
    void *p = malloc_wrap(best);
    if (p) {
        pause();
        return 0;
    }
    else {
        return 1;
    }
}

Ejecutando el programa anterior (./a.out) en mi máquina Linux stanley 2.6.32-24-generic-pae #39-Ubuntu SMP Wed Jul 28 07:39:26 UTC 2010 i686 GNU/Linux obtiene este resultado:

<snip>
Allocated 2919235584 bytes from 0x9763008 to 0xb7763008
Allocated 2936012800 bytes from 0x8763008 to 0xb7763008
Failed to allocated 2952790016 bytes
Failed to allocated 2953838592 bytes
Failed to allocated 2953904128 bytes
Failed to allocated 2953908224 bytes
Allocated 2936012800 bytes from 0x85ff008 to 0xb75ff008

Esta es una asignación de exactamente 2800MiB. Observar el mapeo relevante desde /proc/[number]/maps:

<snip>
0804a000-0804b000 rw-p 00001000 08:07 3413394    /home/matt/anacrolix/public/stackoverflow/a.out
085ff000-b7600000 rw-p 00000000 00:00 0          [heap]
b7600000-b7621000 rw-p 00000000 00:00 0 
b7621000-b7700000 ---p 00000000 00:00 0 
b7764000-b7765000 rw-p 00000000 00:00 0 
b7765000-b78b8000 r-xp 00000000 08:08 916041     /lib/tls/i686/cmov/libc-2.11.1.so
<snip>
bfc07000-bfc1c000 rw-p 00000000 00:00 0          [stack]

Conclusión

Parece que el montón se ha expandido en el área entre los datos del programa y el código, y las asignaciones de bibliotecas compartidas, que se ajustan perfectamente al límite del espacio de memoria del usuario/kernel (obviamente 3G/1G en este sistema).

Este resultado sugiere que el espacio máximo asignable usando malloc es aproximadamente igual a:{[18]]}

1. La región del espacio de usuario (3GB en el ejemplo)
2. Menos el desplazamiento al inicio de el montón (código de programa y datos)
3. Menos el espacio reservado para la pila de subprocesos principal
4. Menos el espacio ocupado por todos los mapeados en bibliotecas compartidas
5. Finalmente, la región contigua más grande que se puede encontrar por la llamada al sistema subyacente dentro de la región disponible para el montón (que puede estar fragmentada por otras asignaciones)

Notas

Con respecto a las implementaciones de glibc y Linux, los siguientes fragmentos de manual son de gran interés:

malloc

   Normally, malloc() allocates memory from the heap, and adjusts the size
   of the heap as required, using sbrk(2).  When allocating blocks of mem‐
   ory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation
   allocates the memory as a  private  anonymous  mapping  using  mmap(2).
   MMAP_THRESHOLD  is  128  kB  by  default,  but is adjustable using mal‐
   lopt(3).

mmap

   MAP_ANONYMOUS
          The mapping is not backed by any file; its contents are initial‐
          ized to zero.

Epílogo

Esta prueba se realizó en un kernel x86. Esperaría resultados similares de un kernel x86_64, aunque con regiones de memoria mucho más grandes devueltas. Otros sistemas operativos pueden variar en su colocación de asignaciones, y el manejo de mallocs grandes, por lo que los resultados podrían ser bastante diferentes.