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(at)svana(dot)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