¿Las implementaciones malloc devolverán la memoria de edición libre al sistema?

La mayoría de las implementaciones no se molestan en identificar aquellos casos (relativamente raros) donde "bloques" enteros (de cualquier tamaño que se adapte al sistema operativo) han sido liberados y podrían ser devueltos, pero hay, por supuesto, excepciones. Por ejemplo, y cito de la página de wikipedia , en OpenBSD:

En una llamada a free, la memoria se libera y sin asignar desde la dirección del proceso espacio usando munmap. Este sistema es diseñado para mejorar la seguridad tomando ventaja del espacio de direcciones diseño características de la página de aleatorización y brecha implementado como parte de la mmap llamada al sistema, y para detectar usar-después-errores libres - como una memoria grande la asignación está completamente sin asignar después de que se libera, otras causas de uso un fallo de segmentación y terminación del programa.

Sin embargo, la mayoría de los sistemas no están tan centrados en la seguridad como OpenBSD.

Sabiendo esto, cuando estoy codificando un sistema de larga duración que tiene un requisito conocido como transitorio para una gran cantidad de memoria, siempre intento fork el proceso: el padre entonces solo espera los resultados del hijo [[típicamente en una tubería]], el hijo hace el cálculo (incluyendo la asignación de memoria), devuelve los resultados [[en dicha tubería]], luego termina. De esta manera, mi proceso de larga duración no estará acaparando inútilmente la memoria durante los largos tiempos entre "picos" ocasionales en su demanda de memoria. Otras estrategias alternativas incluyen cambiar a un asignador de memoria personalizado para tales requisitos especiales (C++ hace que sea razonablemente fácil, aunque los lenguajes con máquinas virtuales debajo, como Java y Python, generalmente no lo hacen).

Estoy tratando con el mismo problema que el OP. Hasta ahora, parece posible con tcmalloc. Encontré dos soluciones:

1. Compila tu programa con tcmalloc linked, luego ejecútalo como:

   env TCMALLOC_RELEASE=100 ./my_pthread_soft
   

   La documentación menciona que

   Las tasas razonables están en el rango [0,10].

   Pero 10 no me parece suficiente (es decir, no veo ningún cambio).

2. Encuentre algún lugar en su código donde sería interesante liberar todo la memoria liberada, y luego añadir este código:

   #include "google/malloc_extension_c.h" // C include
   #include "google/malloc_extension.h"   // C++ include
   
   /* ... */
   
   MallocExtension_ReleaseFreeMemory();
   

La segunda solución ha sido muy efectiva en mi caso; la primera sería genial pero no es muy exitosa, es complicado encontrar el número correcto por ejemplo.

Para todos los mallocs 'normales', incluidos los que ha mencionado, la memoria se libera para ser reutilizada por su proceso, pero no para todo el sistema. La liberación de nuevo a todo el sistema ocurre solo cuando el proceso se termina finalmente.

De los que enumere, solo Hoard devolverá memoria al sistema... pero si realmente puede hacer eso dependerá mucho del comportamiento de asignación de su programa.

Tuve un problema similar en mi aplicación, después de algunas investigaciones me di cuenta de que por alguna razón glibc no devuelve la memoria al sistema cuando los objetos asignados son pequeños (en mi caso menos de 120 bytes).
Mira este código:

#include <list>
#include <malloc.h>

template<size_t s> class x{char x[s];};

int main(int argc,char** argv){
    typedef x<100> X;

    std::list<X> lx;
    for(size_t i = 0; i < 500000;++i){
        lx.push_back(X());
    }

    lx.clear();
    malloc_stats();

    return 0;
}

Salida del programa:

Arena 0:
system bytes     =   64069632
in use bytes     =          0
Total (incl. mmap):
system bytes     =   64069632
in use bytes     =          0
max mmap regions =          0
max mmap bytes   =          0

Alrededor de 64 MB no se devuelven al sistema. Cuando cambié typedef a: typedef x<110> X; la salida del programa se ve así:

Arena 0:
system bytes     =     135168
in use bytes     =          0
Total (incl. mmap):
system bytes     =     135168
in use bytes     =          0
max mmap regions =          0
max mmap bytes   =          0

Casi toda la memoria fue liberada. También me di cuenta de que el uso de malloc_trim(0) en cualquier caso liberado memoria a sistema.
Aquí está la salida después de agregar malloc_trim al código anterior:

Arena 0:
system bytes     =       4096
in use bytes     =          0
Total (incl. mmap):
system bytes     =       4096
in use bytes     =          0
max mmap regions =          0
max mmap bytes   =          0

La respuesta corta: Para forzar que el subsistema malloc devuelva memoria al sistema operativo, use malloc_trim(). De lo contrario, el comportamiento de la memoria devuelta depende de la implementación.