Sim, talvez seja a terceira vez que você vê esse código, porque eu fiz duas outras perguntas sobre ele (esta eesta) .. O código é bastante simples:

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

Então eu o construo e executo com o Valgrind no 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)

Aqui, Valgrind relata que não há vazamento de memória, embora haja 1 alocação e 0 livres.

A respostaaqui ressalta que o alocador usado pela biblioteca padrão C ++ não retorna necessariamente a memória de volta ao sistema operacional - pode mantê-los em um cache interno.

Questão é:

1) Por que mantê-los em um cache interno? Se é para velocidade,quão é mais rápido? Sim, o sistema operacional precisa manter uma estrutura de dados para controlar a alocação de memória, mas isso também é necessário pelo mantenedor desse cache.

2) Como isso é implementado? Porque meu programaa.out já termina, não há outro processo que esteja mantendo esse cache de memória - ou existe algum?

Edit: for question (2) - Algumas respostas que eu vi sugerem "C ++ runtime", o que isso significa? Se "C ++ runtime" for a biblioteca C ++, mas a biblioteca for apenas um monte de código de máquina no disco, não será um processo em execução - o código da máquina está vinculado ao meua.out (biblioteca estática,.a) ou é chamado durante o tempo de execução (objetos compartilhados,.so) no processo dea.out.