Re: Returning memory to the OS
On Oct 10, 4:10 pm, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
On 09/10/09 22:17, Jan Bielawski wrote:
I have a multi-platform STL question (multi-platform means
Windows 32, 64, Linux 64-bit, Mac OS). I'd like for an STL
vector to return the memory to the OS - not just to the heap
- upon deallocation, like exiting the scope. I wrote an
allocator with the usual ::operator delete in its
deallocate() function:
void deallocate(pointer p, size_type num) {
::operator delete((void *)p);
}
...but this does not necessarily return the memory to the
OS. I found the function _heapmin() on MSDN web site and it
seems to work for Windows XP 32-bit:
void deallocate(pointer p, size_type num) {
::operator delete((void *)p);
#ifdef WIN32
_heapmin(); // memory goes away stepping past this line
#endif
}
My first question is: is this the way to go about it in
general?
You would need to create another allocator that would do the
required memory management and instantiate std::vector<> with
it. Not very practical for your purpose though because one of
the design goals of std::vector<> is to hide memory management
details from the user while you seem to want to manage memory
explicitly.
Yes and no. std::vector<> would still take care of the basic
decisions concerning how much to allocate and to free, and when.
A simple memory manager going directly to the OS each time
shouldn't be too difficult (using an anonymous mmap under Unix);
more likely, however, you'd want to be a little bit more
sophisticated, and only go directly to the OS for allocations
larger than some specific size, using the operator new and the
operator delete functions otherwise.
If you just need a huge array you could allocate it directly from the OS
using POSIX mmap() call or VirtualAlloc() call on Windoze. The
interesting bit here is that operating systems like Linux and Windoze do
demand paging, i.e. mmap() call only reserves a portion of process
virtual address space without actually allocating any memory. Memory is
allocated on demand by pages (most often 4096 bytes on x86)
transparently when you first actually write or read that mmap()ed
memory, thus demand paging.http://en.wikipedia.org/wiki/Demand_paging
Except that it's not so transparent as that. It can't be; if
there are no pages left, the system has to do something. And
that something is generally very unpleasant, involving processes
getting killed or hanging. Luckily, this feature can be turned
off under Linux, since you can't write serious software when it
is active.
--
James Kanze