Sí, esta podría ser la tercera vez que vea este código, porque le hice otras dos preguntas al respecto (esta yesta) .. El código es bastante simple:

#include <vector>
int main() {
    std::vector<int> v;
}

Luego lo construyo y lo ejecuto con Valgrind en Linux:

g++ test.cc && valgrind ./a.out
==8511== Memcheck, a memory error detector
...
==8511== HEAP SUMMARY:
==8511==     in use at exit: 72,704 bytes in 1 blocks
==8511==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==8511==
==8511== LEAK SUMMARY:
==8511==    definitely lost: 0 bytes in 0 blocks
==8511==    indirectly lost: 0 bytes in 0 blocks
==8511==      possibly lost: 0 bytes in 0 blocks
==8511==    still reachable: 72,704 bytes in 1 blocks
==8511==         suppressed: 0 bytes in 0 blocks
...
==8511== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Aquí, Valgrind informa que no hay pérdida de memoria, a pesar de que hay 1 aloc y 0 libre.

La respuestaaquí señala que el asignador utilizado por la biblioteca estándar de C ++ no necesariamente devuelve la memoria al sistema operativo, podría mantenerlos en una memoria caché interna.

La pregunta es:

1) ¿Por qué mantenerlos en un caché interno? Si es por velocidad,cómo ¿Es más rápido? Sí, el sistema operativo necesita mantener una estructura de datos para realizar un seguimiento de la asignación de memoria, pero este también es el responsable del mantenimiento de esta memoria caché.

2) ¿Cómo se implementa esto? Porque mi programaa.out ya termina, no hay otro proceso que mantenga esta memoria caché, o ¿hay alguno?

Editar: para la pregunta (2) - Algunas respuestas que he visto sugieren "tiempo de ejecución C ++", ¿qué significa? Si "C ++ runtime" es la biblioteca de C ++, pero la biblioteca es solo un montón de código de máquina que se encuentra en el disco, no es un proceso en ejecución: el código de máquina está vinculado a mia.out (biblioteca estática,.a) o se invoca durante el tiempo de ejecución (objetos compartidos,.so) en el proceso dea.out.