Will Visual C++ runtime malloc / free return memor

Question

The question is a lot similar to Will malloc implementations return free-ed memory back to the system?, but I am interested about an answer for Windows / Microsoft Visual Studio, and about details on the exact virtual memory state.

Will Visual C++ CRT free return the memory back to the system? What will be the exact state of the memory in respect to virtual memory allocations? After doing free on a large memory block, will the memory in the block be committed, reserved, or free? What if I call _heapmin after the free?

Answer 1

No, it will not return memory to "the system". _heapmin only frees whole pages that are empty, and often has little effect. It does not shuffle data between pages. So, it depends where in the heap memory is freed, as to whether a combination of free() and _heapmin will actually reduce the number of pages in use or not. Note also that VS uses a different heap for Debug and Release.

For more control, see HeapCreate()/HeapAlloc() etc. APIs.

Answer 2

Inspecting the source code for 2010, it can be seen malloc/free call HeapAlloc/HeapFree Win32 API functions directly, with a _crtheap as a heap created by the runtime. The answer for VS 2010 and recent Windows versions (Win2000, WinXP, Vista, Win 7) therefore is:

The memory returned by the free is returned to OS, but it stays committed.

Heap Functions documentation says following regarding how is the memory commitment handled:

The HeapCreate function creates a private heap object from which the calling process can allocate memory blocks by using the HeapAlloc function. ... Additional pages are automatically committed from this reserved space if requests by HeapAlloc exceed the current size of committed pages, assuming that the physical storage for it is available. Once the pages are committed, they are not decommitted until the process is terminated or until the heap is destroyed by calling the HeapDestroy function.

Moreover HeapCreate documentation says following regarding the case of a heap with no maximum size set:

If dwMaximumSize is 0, the heap can grow in size. The heap's size is limited only by the available memory. Requests to allocate memory blocks larger than the limit for a fixed-size heap do not automatically fail; instead, the system calls the VirtualAlloc function to obtain the memory that is needed for large blocks. Applications that need to allocate large memory blocks should set dwMaximumSize to 0.

I did not find anything which would say whether those block allocated using VirtualAlloc are handled in a special way when released, an experiment would probably be needed to know this.

As for _heapmin, with VS 2010 is does nothing, as it only calls HeapCompact and the CRT heap does not have automatic coalesce on free turned off. The documentation for _heapmin therefore seems wrong, most likely a relic from some old version of the runtime.