4 ms·
Years ago I read in the Perl documentation ( http://perldoc.perl.org/perlfaq3.html#How-can-I-free-an-array-or-hash-so-my-program-shrinks%3f http://perldoc.perl.
by maxlybbert 9y ago
Years ago I read in the Perl documentation ( http://perldoc.perl.org/perlfaq3.html#How-can-I-free-an-array-or-hash-so-my-program-shrinks%3f http://perldoc.perl.org/perlfaq3.html#How-can-I-free-an-arra... ):
> On most operating systems, memory allocated to a program can never be returned to the system. ... Some operating systems (notably, systems that use mmap(2) for allocating large chunks of memory) can reclaim memory that is no longer used ...
Because you can't return unneeded memory to most operating systems (or because it used to be that you couldn't return unneeded memory, even if that has changed recently), it isn't a surprise that by default GCC's free() and operator delete -- which are meant to be cross platform -- don't try to return that memory. Instead it's all free list management.
I do think it's silly for operators new/delete to have a separate free list from malloc()/free().
- gpderetta 9y ago>I do think it's silly for operators new/delete to have a separate free list from malloc()/free(). They don't. This is a custom, simple, non-default pool allocator for standard containers (i.e nothing to do with new)
- maxlybbert 9y agoThanks for the correction. But it's just as silly to create an allocator for the standard containers, when the allocator consists of little more than free list management, given that malloc/free and new/delete already do that. It's especially silly for a library (programs may want custom memory management and libraries really shouldn't go out of their way to make that harder), and the fact that it's the standard library doesn't make it less silly.
- jwakely 9y agoGCC's std::allocator also doesn't do that (not for at least a decade, IIRC). It's a non-default allocator, which nobody is forced to use. It's entirely optional. The default std::allocator just uses new/delete.