Why the memory not freed in top and pmap?

I have check the code with valgrind, no memory leak. but I use 'top' to see the memory, it cost 295MB memory after the 'delete' called.
I use 'pmap -x' to see the memory, most memory cost by a [anon]:

Address           Kbytes     RSS   Dirty Mode   Mapping
0000000001114000  301672  301588  301588 rw---    [ anon ]

I don't know why the memory has been freed, but it's still cost 295MB. Anyone know why?

#include <map>
#include <string>
#include <iostream>
#include <stdio.h>
using namespace std;
void test8() {
  map<string, map<string,string>* > m;
  for (int i = 1; i < 10000; i++) {
    map<string, string>* p = new map<string, string>();
    for (int j = 1; j < 100; j++) {
      (*p)[string(j,'a')] = string(j,'a');
    }
    m[string(i,'a')] = p;
  }

  map<string, map<string,string>* >::iterator it;
  for (it = m.begin(); it != m.end(); it++) {
    it->second->clear();
    delete it->second;
  }
  m.clear();
  cout << "free done" << endl;
}
int main(int argc, char**argv) {
  test8();
  getchar();
}

Solution

Caching, caching, caching. Oh yeah, and fragmentation.

Memory is allocated via different layers. If your application allocates memory, it will ask it to the C/C++ runtime. The C/C++ runtime will check its own datastructures for available memory, and if it doesn't have any, it will forward the call to the OS. Depending on the C/C++ runtime (and version), the C/C++ runtime data structures might be extensive, or the C/C++ runtime might simply always forward the call to the OS directly. For Microsoft Visual Studio (not using Linux at this moment, sorry), I know that:

Older versions had quite extensive memory data structures in the C/C++ runtime
Newer versions seem to always forward the call to the OS (Windows Heap)

This means that when deallocate memory, the C/C++ runtime might decide to keep the memory (for several reasons, including being able to return memory quicker if you decide to allocate memory again), or might return it to the OS (if it already has lots of free memory). The OS might do exactly the same: keep the memory ready in case you want to allocate it again, or mark it as deallocated immediately.

Oh yeah, fragmentation. Memory is typically divided in pages. On Intel x86 and amd64 a page is 4KB. Every page contains some information including:

protection rights (read-only, read-write, execute (see DEP, NoX bit)
its actual place (physical memory, paged out to the pagefile, ...)

Suppose your application allocates 16 times 256 bytes, and you are lucky enough that all this memory is allocated within one page of 4KB. If you now free 15 of these allocations, the 16th allocation will keep the memory page allocated, preventing the OS from marking it deallocated. It's quite easy to write an application that allocates 1.5GB, and then frees 1.4GB of it, and still consume 1.5GB of memory (according to the OS).

This means that even if you deallocated all memory, there might just be some internal C/C++ runtime data structures, or some 3rd party data structures (maybe some cache) that might keep some pages allocated, although you perfectly deallocated all of your memory.