On Sun, Feb 18, 2001 at 09:44:33PM -0700, Erik Huizing wrote:
> How often are memory blocks marked by free() actually freed?
> 
> After noticing one of my programs seemed to be accumulating memory, even
> though I knew I was freeing it as it ran. So I wrote a small program,
> which allocates a chunk of memory, uses it and frees it. I've watched what
> happens on top, and the memory doesn't appear to get freed until the
> program exists. 'ps' tells me the same story:
> 
> USER       PID %CPU %MEM   VSZ  RSS TT  STAT STARTED       TIME COMMAND
> erik      5368  0.0  0.8   164  508 p2  S+    9:26PM    0:00.04 foo
> erik      5368 12.8 30.8 32936 20056 p2  S+    9:26PM    0:01.29 foo
> after printing 'freed', I still get this:
> erik      5368  2.1 30.8 32936 20056 p2  S+    9:26PM    0:01.29 foo
> 
> Is there a way to have the memory I'm freeing be released without needing
> my program to exit?

When you malloc() memory, free() it, and then malloc() more memory then
the memory you used previously should be returned to you again at the
second malloc().  

Calls to malloc() will increase the break size (or mmap /dev/null or
similar) by doing system calls. Since system calls are expensive, free()
doesn't return memory to the kernel because often it will just be 
malloc()'d again. This is an optimization for time at the expense of
space.

If you have a program that malloc()'s memory and is supposed to free() it
but in fact grows unexpectedly large then you may have a memory leak
in your program.

Note that you may end up with internal fragmentation if you malloc a bunch
of little pieces of memory and then free some of them. This can throw
off calculations of how much vm your program "should" be using.

(If you really, really, really insist on giving the memory back to the
kernel when you are done with it then you can either exit or write your
own memory allocation system. Buying a larger disk is often more cost
effective.)
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

"It sounded pretty good, but it's hard to tell how it will work out
in practice." -- Dennis Ritchie, ~1977, "Summary of a DEC 32-bit machine"