> > On Tue, 28 Jan 1997, Mark Hemment wrote:
>
> > malloc() and free() are library funcs, not system calls.
>
> Exactly what I stated in the message. I also stated that it wasn't a
> kernel bug. I also stated where the BUG existed. I also suggested that
> the maintainer of the C runtime library look into this.
They have looked into this for years. What version of the C library
are you running ? Versions from 5.3.x onward contain a new
high-performance malloc implementation which internally uses mmap()
for large chunks. With such a libc, it is _guaranteed_ that any
chunk >128k (this is the default threshold, tunable via mallopt())
_is_ returned to the system on a free(), immediately.
> > malloc() may sbrk() up the data segment to get more memory,
> > but not all implementations of free() will sbrk() down. Therefore
> > free()d memory will not be returned to the OS, but will stay in a
> > process's address space.
> > For malloc engines which use sbrk() and can return memory to the
> > system, the conditions which allow this are limited.
This is true, but the current implementation (due to Doug Lea) has
been optimized to group large chunks together and return memory with
sbrk(-x) as well, if at all possible and worthwhile (at least 128k).
> > It is possible to write malloc()/free() to use mmap()/unmap(), maybe
> > SunOS 5.5.1 does this (but then again, maybe not).
Linux with recent libc does this, too.
Regards,
Wolfram.
-- `Surf the sea, not double-u three...' Wolfram.Gloger@dent.med.uni-muenchen.de, Gloger@lrz.uni-muenchen.de