Re: Table Garbage Collection

["Nick Nugent" <nugent@...>]

On 11/22/06, Rob Kendrick wrote:
> On Wed, 2006-11-22 at 16:40 -0500, Javier Guerra wrote:
> > in Linux (like any Unix, AFAIK), it's very rare for a process to return memory
> > to the OS; any free()'d memory is returned to an in-process free list.  the
> > process size (as reported by /proc, ps, top, and friends) is roughly the max
> > size it has reached.
>
> Additionally, the reason for this is that the memory is allocated
> logically in a flat space, so if you have one block still allocated
> right at the end, but megabytes of free memory before it, this can't
> easily be returned to the OS if the memory was allocated by brk() (which
> extends the process's memory.)
>
> What happens may be very different if the memory was allocated via
> mmap(), however.

All right, that is a satisfying if frustrating answer.  I've verified
that the interpreter does end up calling brk(), of course, in which
case it would all seem to make sense.

I came across this trying to write some benchmark and memory leak
analysis utilities for a Lua-fronted package using the C API.  The
real application would likely never grow so large in the first place,
as it would be garbage collecting along the way.  It seems it is not
quite appropriate to benchmark the garbage collector in this manner,
and that what I thought was a red flag turns out to be a red herring
instead.

As an interesting follow up, a second loop that allocates out of the
"free" region as before, though not quite as much as the first, which
is then garbage collected again returns the VM almost to its original
size.  Weird.

In any case, thanks for the help.

--Nick