Davi de Castro Reis <davicastro@terra.com.br> writes:
Hi guys,
Does anyone know how to release all the memory allocated by STL? Just let me say why I want to do this. The software I am working on uses STL a lot in its first phase. I allocate nearly a 1GB of memory in a lot of different STL containers.
What kind of containers and how big are the objects in them?
In the second phase of the software, I clear() all these container and start a custom algorithm that also uses a lot of memory. But the STL memory pool is holding quite a lot of memory, and I run out of memory in the middle of the algorithm.
What kind of memory allocation do you use in the second phase?
If I run the two phases of the software in different binaries, everything is ok and my algorithm fits in memory. There are no leaks that I am aware of in the software (I've already made a lot of valgrind checks).
I do not want to use -D__USE_MALLOC or GLIBCPP_FORCE_NEW=1, since I do want the performance of the STL memory pool. I just want to release this pool during one of the phases of my software.
The pool is only used for nodes smaller than 128 bytes, and as you have noticed there is no public/documented/legal way to release memory from the pool. Therefore if you, for example, are using a list, map, or set with small nodes your only choice is to write your own custom allocator. Copying the pool allocator template from: /usr/include/g++/bits/stl_alloc.h and adding a member function to deallocate the pool to your version might be an acceptable solution. Before you get that far, are you sure that your memory is coming from the pool? If you are using vectors for instance, you probably are allocating much larger blocks and totally bypassing the pool. If so, then you might want to know about the "swap trick" (Item 17 in Scott Meyers' "Effective STL"): vector<Stuff> big_vector; ... ... // use big_vector ... vector<Stuff>().swap(big_vector); // clear big_vector and // minimize its capacity because clear() does not decrease the capacity of a vector or deallocate any memory. Since you are apparently already deep enough into your problem to have found the "pool" I really hesitate to suggest this, but I just finished reading "Effective STL" so I couldn't keep my mouth shut :-)