This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libc-alpha Digest 20 Sep 2018 12:41:32 -0000 Issue 6574
- From: DJ Delorie <dj at redhat dot com>
- To: Chris Aoki <christopher dot aoki at oracle dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 20 Sep 2018 13:43:03 -0400
- Subject: Re: libc-alpha Digest 20 Sep 2018 12:41:32 -0000 Issue 6574
Chris Aoki <christopher.aoki@oracle.com> writes:
> If the system is fragmented at the mmap level, would it be possible
> to find mmaps consisting entirely of free blocks (coalescing if necessary)
> and unmap them? e.g. by equipping each mapping with a total-free-space
> counter?
Interesting idea, but we grow heaps contiguously at the moment. The
only time we release memory back to the system, it's at the end of the
heap. So the only way to free up a mapping would be to free an entire
heap, or grow a heap so it touches an adjacent one.
Maybe that's a good idea anyway, of course, assuming we can find a heap
that's 100% free - we'd have to even purge the tcache to ensure that,
assuming the application isn't holding a pointer to a chunk therein.
I suspect most of the mmap fragmentation that's malloc's fault is the
large allocations that are done via mmap instead of the heap, but
there's nothing we can do about those if the application hasn't freed
them.