Re: Virtual Bytes is STL

anand chugh wrote:


Here's a bit more hopefully correct info/clarification:

MS's (actually, Dinkumware's) STL implementation does *not* cache memory
(unlike SGI's) - it returns it straight back to the OS, ultimately using
the Win32 function HeapFree.

HeapAlloc/HeapFree are part of the OS, not the compiler/library, and can
behave in a variety of ways dependent on OS and whether the LFH is
configured. Large single allocations for HeapAlloc/Free are ultimately
handled by VirtualAlloc/VirtualFree (I think allocations > 4mb?), and
therefore do not result in growth in virtual memory usage once they have
been freed. Smaller allocations are serviced by HeapAlloc reserving
chunks of virtual memory and then committing/decommitting them as
needed. However, I don't think that the standard XP/Vista heap algorithm
ever calls VirtualFree, so virtual memory is never recovered (it is of
course reused).

HeapDestroy(GetProcessHeap()) would be required to release virtual
memory that has been reserved by the process heap (and therefore the
STL), but that call is illegal (read the documentation for HeapDestroy).

Finally, none of this matters, since virtual memory reservations do not
impact anything outside of a process. Perhaps your test program has an
actual memory leak, since private bytes should not be increasing as it
seems to be for you.

Tom