Question

I have noticed some interesting behavior in Linux with regard to the Memory Usage (RES) reported by top. I have attached the following program which allocates a couple million objects on the heap, each of which has a buffer that is around 1 kilobyte. The pointers to those objects are tracked by either a std::list, or a std::vector. The interesting behavior I have noticed is that if I use a std::list, the Memory Usage reported by top never changes during the sleep periods. However if I use std::vector, the memory usage will drop to near 0 during those sleeps.

My test configuration is:
Fedora Core 16
Kernel 3.6.7-4
g++ version 4.6.3

What I already know:
1. std::vector will re-allocate (doubling its size) as needed.
2. std::list (I beleive) is allocating its elements 1 at a time
3. both std::vector and std::list are using std::allocator by default to get their actual memory
4. The program is not leaking; valgrind has declared that no leaks are possible.

What I’m confused by:
1. Both std::vector and std::list are using std::allocator. Even if std::vector is doing batch re-allocations, wouldn’t std::allocator be handing out memory in almost the same arrangement to std::list and std::vector? This program is single threaded after all.
2. Where can I learn about the behavior of Linux’s memory allocation. I have heard statements about Linux keeping RAM assigned to a process even after it frees it, but I don’t know if that behavior is guaranteed. Why does using std::vector impact that behavior so much?

Many thanks for reading this; I know this is a pretty fuzzy problem. The ‘answer’ I’m looking for here is if this behavior is ‘defined’ and where I can find its documentation.

#include <string.h>
#include <unistd.h>
#include <iostream>
#include <vector>
#include <list>
#include <iostream>
#include <memory>

class Foo{
public:
    Foo()
    {
        data = new char[999];
        memset(data, 'x', 999);
    }

    ~Foo()
    {
        delete[] data;
    }

private:
    char* data;

};

int main(int argc, char** argv)
{
    for(int x=0; x<10; ++x)
    {
        sleep(1);
        //std::auto_ptr<std::list<Foo*> > foos(new std::list<Foo*>);
        std::auto_ptr<std::vector<Foo*> > foos(new std::vector<Foo*>);
        for(int i=0; i<2000000; ++i)
        {
            foos->push_back(new Foo());
        }
        std::cout << "Sleeping before de-alloc\n";
        sleep(5);
        while(false == foos->empty())
        {
            delete foos->back();
            foos->pop_back();
        }
    }
    std::cout << "Sleeping after final de-alloc\n";
    sleep(5);
}

Answer 1

The freeing of memory is done on a “chunk” basis. It’s quite possible that when you use list, the memory gets fragmented into little tiny bits.

When you allocate using a vector, all elements are stored in one big chunk, so it’s easy for the memory freeing code to say “Golly, i’ve got a very large free region here, I’m going to release it back to the OS”. It’s also entirely possible that when growing the vector, the memory allocator goes into “large chunk mode”, which uses a different allocation method than “small chunk mode” – say for example you allocate more than 1MB, the memory allocation code may see that as a good time to start using a different strategy, and just ask the OS for a “perfect fit” piece of memory. This large block is very easy to release back to he OS when it’s being freed.

On the ohter hand if you are adding to a list, you are constantly asking for little bits, so the allocator uses a different strategy of asking for large block and then giving out small portions. It’s both difficult and time-consuming to ensure that ALL blocks within a chunk have been freed, so the allocator may well “not bother” – because chances are that there are some regions in there “still in use”, and then it can’t be freed at all anyways.

I would also add that using “top” as a memory measure isn’t a particularly accurate method, and is very unreliable, as it very much depends on what the OS and the runtime library does. Memory belonging to a process may not be “resident”, but the process still hasn’t freed it – it’s just not “present in actual memory” (out in the swap partition instead!)

And to your question “is this defined somewhere”, I think it is in the sense that the C/C++ library source cod defines it. But it’s not defined in the sense that somewhere it’s written that “This is how it’s meant to work, and we promise never to hange it”. The libraries supplied as glibc and libstdc++ are not going to say that, they will change the internals of malloc, free, new and delete as new technologies and ideas are invented – some may make things better, others may make it worse, for a given scenario.

As has been pointed out in the comments, the memory is not locked to the process. If the kernel feels that the memory is better used for something else [and the kernel is omnipotent here], then it will “steal” the memory from one running process and give it to another. Particularly memory that hasn’t been “touched” for a long time.