memory leak on solaris 2.5.1 / 2.6 ?

[Thomas Wouters]

On Wed, May 31, 2000 at 06:49:33PM +0200, Wolfgang Grafen wrote:
> William Annis wrote:

> >         Right.  Solaris assumes that if you ask for a chunk of memory,
> > you are probably going to ask for it again later, even after a free().

> What is it for? After consuming the fast silicon main memory the
> process slows extremely down when swapping to disk although
> it could demand freed memory!

The memory that is malloc()ed and later free()ed (wether it's been used or
not, on most UNIX systems, or only if it's used, on systems that use GNU
libc (or at least I assume)) is marked as free, but stays part of the
process's memory segment. Later calls to malloc() that fit somewhere in the
unused parts of the memory segment (the 'heap') do not cause another memory
allocation.

The difference my seem strange, but comes from the way the UNIX kernel and
the C runtime (libc) share responsibilities. malloc() is a library call, and
does a lot of bookkeeping for the programmes' sake. The logic behind
malloc() is too complex for the average UNIX kernel; the kernel has a very
simplified take on processes: each has a stack, for automatic variables and
call frames, and a heap, for all other kinds of memory allocation. The heap
is just a block of memory, which you can grow using brk() or sbrk().

This is very nice for the kernel, because it has a lot less bookkeeping to
do, but not very nice for the programmer, who has a lot more bookkeeping to
do. So that's where the C runtime comes in, simplifying the programmers task
by allowing a simple malloc()/free() system. libc keeps a list of all
malloc()ed memory, increases the heap in size if it needs to, and does its
best to do that as little as possible.

And let's thank the gods for malloc()... Managing memory is hard enough
*with* malloc, let alone without it ;-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!