Vector <string> does not free memory after exiting area

Question

I ran into the following problem, and I'm not sure if I am mistaken or her really weird mistake. I fill in a huge array of strings and want it to be cleared at some point. Here is a minimal example

#include <string> #include <vector> #include <unistd.h> //sleep #include <iostream> int main(){ { std::vector<std::string> strvec; for(long i = 0; i < 1000000; ++i){ std::string out = "This is gonna be a long string just to fill up the memory used by this fucking pthread\n"; strvec.push_back(out); } std::cout << "finished loading 1st\n"; sleep(10); // to monitor any changes } std::cout << "out of scope\n"; sleep(10); return 0; } 

My problem is that if I control the memory usage with "top", then the memory usage is only reduced by a very small amount (I think this is probably the overhead of the vector), but most of them seem to be not freed. How's it going? I tested the same script with a "long long" one, but everything went right here.

The std :: vector reference indicates that if the contained values ​​are not pointers, destructors are invoked. This seems to be wrong for the string though ...

I appreciate every answer.

(for convenience: I am using debian linux 64Bit with g ++ 4.7.2)

EDIT: thanks for the answers so far.

By now, I have a profiled use of a heap with an array of wagrind, and (yes, actually, as expected) it gets duly released at the point at which it should. But why do I really see changes in use with a huge integer, but not with strings (also from top to bottom)?

I need to know a little about this, because I should be able to free my memory at a certain time for a multi-threaded server application, which is likely to work for several weeks or more without restarting. When do I really know when the C ++ memory manager decides to return some memory back to the OS?

Answer 1

It depends on the use of the top command and not on std::vector . The problem is that the memory freed by data structures does not return back to the operating system, the level at which the top command controls memory usage. The memory provided by the OS by your program remains with your program until the C ++ memory manager decides that it is time to free some memory back to the operating system.

The reason for this is that allocating memory from the operating system is relatively expensive, and this needs to be done in relatively large chunks. The C ++ runtime library memory manager receives memory from the OS "wholesale", and then sends it as part of your program as necessary.

If you want to check if the memory is actually recovered, use a tool that tracks memory usage at a lower level, like valgrind .

Answer 2

Even if you free memory correctly, the standard library does not need to free memory back to the OS.

So, for example, when you first allocate all the memory, the library allocates a bunch of virtual memory address space from the OS (probably with mmap(2) ) and reduces it. But when you finish working with this memory, it freezes in the virtual address space on the assumption that you may need this memory later, so it does not call munmap(2) to disable the virtual address space.

Therefore, although all the memory was correctly freed from the perspective of your program, all the OS sees that you allocated a bunch of virtual memory, but then did not release it. Therefore, top(1) reports that your memory usage is not decreasing, but there is nothing to worry about. When your program again needs memory, it will allocate it from the virtual address space that you already have, so you will not see an increase in the amount of visible memory until all this memory is exhausted.

Answer 3

As indicated in other answers, the memory is still available for your process and is not freed up until the program terminates. If you want the dispenser to do this, you can check out the use of jemalloc, which can free it back into the OS, and is very useful in scalable multi-threaded applications like facebook, but, as with anything, there are other costs.