What happens to a bunch of Vista?

Question

I'm trying to better understand why a bunch of Windows Vista behaves the way it does. Consider the following very simple program:

#include <vector> #define NUM_ALLOCS 10000000 int _tmain(int argc, _TCHAR* argv[]) { for (int iteration=0; iteration<10000; ++iteration) { std::vector<unsigned char *> buffer; buffer.reserve(NUM_ALLOCS); for (int i=0;i<NUM_ALLOCS;++i) { buffer.push_back(new unsigned char); } for (int i=0;i<NUM_ALLOCS;++i) { delete buffer[i]; } } return 0; } 

This is basically a loop that allocates many 1 byte blocks for each iteration, and then frees them. Naturally, the memory usage of this program increases when buffers are allocated, and then down when the buffers are freed.

The behavior that I see in the 64-bit version of Windows Vista is that peak memory usage (as reported by the task manager or vmmap ) remains roughly constant over time, while the smallest memory consumption grows until it approaches peak memory.

On a 64-bit version of Windows 7, the lowest memory used does not grow over time.

Edit: I tested on two 64-bit Windows Vista machines with 8 GB / 4 GB RAM and one 64-bit Windows 7 machine with 4 GB RAM. I tested an 8 gigabyte machine with low and high memory usage.

Edit: I built the above example with Visual Studio 2005 and 2010 with the same result.

This example does not bring anything useful, but the memory usage scenario is similar (albeit highly condensed) to my program, for which I tried to understand why it uses much more memory than it actually does. From what I can tell, the memory is stored by the heap manager.

Does anyone know about heap mechanisms? Do I need to do something to convince the heap manager to completely free the heap memory used? Are there alternative strategies that I should use, for example, to create a separate heap and then destroy it?

Any comments or ideas appreciated!

Answer 1

Could this be a heap with low fragmentation ?

It seems to me that I read somewhere that LFH is enabled by default in Windows 7. However, a quick search did not reveal confirmation, so I could be wrong.

However, there is an easy way to check. Call HeapQueryInformation on a descriptor retrieved from GetProcessHeap and compare the results on different systems.

Answer 2

Have you tried this under the pressure of memory? It makes no sense to release memory unless it needs something else.

Answer 3

atzz is on the right track, but this behavior will happen with any heap - when you call this first "new" one byte in size, the heap is going to allocate a "bucket" and pre-allocate a specific block of memory (probably several times the page size, 4K); this way, when subsequent allocations of the same size arrive, it can very quickly give you memory.

Also, when you call delete, it just indicates that the region is unallocated, but keep it if you want a new object with the same size later.

If the Heap Manager worked as you describe, it will work very slowly because it will have to constantly ask the kernel: "Can you give me another byte?" and "Demap this please!" (this is actually not possible, since the smallest distribution you can ask the kernel to give you is the page size, as I recall)

Answer 4

Small heap-free memory allocations are usually placed on a list, which is used for quick allocation.

Even without this optimization, the mamager heap is free to keep in the heap bucket from which it was allocated. For memory to return to the system (VirtualFree'ed), all blocks in a 64 KB block must be free and combined by the heap manager.