Releasing does not free memory in a Windows / C ++ application

Question

A Windows / C ++ application allocates ~ 1 GB of data in memory with the new operator and processes this data. After processing, the data is deleted.

I noticed that if I started processing again without exiting the application, the second call to the new operator to allocate ~ 1 GB of data would fail.

I would expect Windows to return memory. Could this be better with other Win32 calls, etc.?

Answer 1

I do not think this is a Windows problem. Verify the deletion or deletion [] is correct. Perhaps this will help if you put code that allocates / frees memory.

Answer 2

In most runtime environments, the memory allocated for an application from the operating system remains in the application and rarely returns back to the operating system. Releasing a memory block allows you to reuse the block from the application, but does not free it from the operating system to make it available to other applications.

The Microsoft C Runtime Library attempts to return memory to the operating system by specifying the _heapmin_region call _heap_free_region or _free_partial_region that invoke VirtualFree to release data to the operating system. However, if whole pages in the corresponding area are not empty, then they will not be freed. A common reason for this is caching information and caching containers in C ++.

Answer 3

This may be due to memory fragmentation (in fact, fragmentation of the address space), where various factors contributed to the address space of your program that does not have an available 1gb continuous hole. Actually, I suspect a memory management error (sorry) - are you running your code with leak detection?

Answer 4

Since you use very large blocks of memory, you should use VirtualAlloc () and VirtualFree () , since they allow you to directly place and free pages without the overhead (in memory and time) of interacting with the cumulus manager.

Since you are using C ++, it is worth noting that you can create C ++ objects in the memory you have allocated using the placement of a new one .

Answer 5

This problem is almost certainly memory fragmentation. On 32-bit Windows, the largest contiguous region that you can allocate is around 1.1 GB (because the different DLL files in your EXE range have a wider continuous range). If after freeing the allocation of memory (or loading a DLL or a file with memory mapping) it appears in the middle of your previous region 1 GB, then there will no longer be 1 GB of the region available for your next call, so that the new one allocates 1 GB. Thus, he will fail.

You can visualize this process using the Validator .