http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53169
--- Comment #5 from Antoine Poliakov <antoinep92 at gmail dot com> 2012-04-30
15:27:16 UTC ---
(In reply to comment #2)
> So it's possible to get the memory libstdc+ allocates to be returned to the
> system, but it's under the control of glibc, nothing to do with std::vector or
> libstdc++
>
> If your memory usage patterns don't result in memory being returned then there
> are several posibilities, including not freeing memory when you think you are,
> or fragmenting the heap so that later allocations cannot re-use memory
> returned
> to freelists and must allocate new memory using mmap.
>
> Not a GCC bug though.
Thanks a lot for explaining this, and sorry for the invalid bug report.
There is probably a lot of memory fragmentation going on, but what's bothering
me is that if you launch several processes with { test(); sleep(30); }, waiting
each time for test() to return you will eventually begin to swap and go out of
memory. So the freed memory is not exactly available to other processes: that's
not just a counter problem.
Thanks for your feedback, and the <MMAP_THRESHOLD trick. I'm probably too harsh
on the system allocator and I will probably use a custom allocator using a
memory pool, which will allow me to minimize fragmentation and free the memory
in a predictable way.
I only see unconfirmed and resolved status, not invalid. Can you mark the bug
as invalid, please.
