Re: Sort memory not being released

On Mon, Jun 16, 2003 at 02:58:55PM -0700, Sean Chittenden wrote:
> See if there's an madvise(2) call on Slowaris, specifically, look for
> something akin to (taken from FreeBSD):
>
>      MADV_FREE        Gives the VM system the freedom to free pages, and tells
>                       the system that information in the specified page range
>                       is no longer important.  This is an efficient way of
>                       allowing malloc(3) to free pages anywhere in the address
>                       space, while keeping the address space valid.  The next
>                       time that the page is referenced, the page might be
>                       demand zeroed, or might contain the data that was there
>                       before the MADV_FREE call.  References made to that
>                       address space range will not make the VM system page the
>                       information back in from backing store until the page is
>                       modified again.
>
> That'll allow data that's malloc'ed to be reused by the OS.  If there
> is such a call, it might be prudent to stick one in the sort code just
> before or after the relevant free() call.  -sc

Seems not worth it. That just means you have to remember to re-madvise() it
when you allocate it again. The memory will be used by the OS again (after
swapping it out I guess).

For large allocations glibc tends to mmap() which does get unmapped. There's
a threshold of 4KB I think. Ofcourse, thousands of allocations for a few
bytes will never trigger it.

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> "the West won the world not by the superiority of its ideas or values or
> religion but rather by its superiority in applying organized violence.
> Westerners often forget this fact, non-Westerners never do."
>   - Samuel P. Huntington