In C++, when does a process retain allocated memory even though delete is called?

Question

I would like to understand what is going on in the GCC runtime in the following situation.

I have a C++ program that allocates many blocks of memory and then deletes them. What's puzzling is that the memory is not being returned to the OS by the GCC runtime. Instead, it is still being kept by my program, I assume in case I want to allocate similar chunks of memory in the near future.

The following program demonstrates what happens:

#include <iostream>
using namespace std;

void pause1()
{
    cout << "press any key and enter to continue";
    char ch;
    cin >> ch;
}

void allocate(int size)
{
    int **array = new int*[size];
    for (int c = 0; c < size; c++) {
        array[c] = new int;
    }
    cout << "after allocation of " << size << endl;
    for (int c = 0; c < size; c++) {
        delete array[c];
    }
    delete [] array;
}

int main() {
    cout << "at start" << endl;
    pause1();
    int size = 1000000;
    for (int i = 0; i < 3; i++) {
        allocate(size);
        cout << "after free" << endl;
        pause1();
        size *= 2;
    }
    return 0;
}

I check the amount of memory held by the process at each pause (when it should not be holding any memory at all) by running "ps -e -o vsz,cmd".

The amount held by the process at each pause is the following:

  2648kb - at start  
 18356kb - after allocating and freeing 1,000,000 ints  
  2780kb - after allocating and freeing 2,000,000 ints  
 65216kb - after allocating and freeing 4,000,000 ints  

I'm running on Fedora Core 6 and using GCC 4.1.1.

Answer 1

The memory allocator used by the C library allocates stuff in a variety of ways depending on how big the chunk is. Pages are not always returned to the OS when memory is freed, particularly if you do many small allocations.

Memory can only be returned to the OS on a page-by-page basis, not for small allocations.

If you really need to know, examine the C library source code and instrument it etc.

In C++ you can override the allocators for containers to do your own memory management - you can then do whatever you want (e.g. mmap /dev/zero or whatever)

Answer 2

It depends, normally if you are using a Linux box, the underlying malloc will start allocating stuff in the heap and it will grow, however if you free some big inner chunk it won't be able to free anything till the top part of the heap is freed, as the onyl thing it can do is grow or reduce the heap.

So, If you allocate a huge chunk, later a smaller chunk and then free your bug chunk, it might happen that they are placed in order and till you free the smaller chunk your process won't be able to reduce the heap size.

In your current example it might happen that the first frees you do don't are waiting for next allocations and later they can't be freed because you have something allocated on top of it. Or maybe it won't start freeing till a given memory size.