RE: Re: A non-sucking garbage collector

Tyler Eaves wrote:

>Maybe I'm missing something, but wouldn't that cause one heck 
>of a memory leak?

The copying garbage-collector/memory-manager works by doing a C malloc
of a large "arena" of memory and then simply allocating chunks of memory
from that sequentially.  It doesn't manage the memory by keeping track
of the chunks at all. It is really dumb.  The interpreter just grabs
these chunks and uses them and discards them without calling free.

Then when the memory manager decides too much memory has been wasted, it
does a "flip".  This consists of allocating a new empty arena and then
walking through all the objects in the object store finding all
reachable objects.  Every time it finds an object it copies it from the
old arena to the new one.  When it is done it does a C free() of the
entire old arena which frees up all the old garbage all at once. In
addition the good objects are now packed efficiently in the new arena.  

This works just as well with tiny objects as it does with large objects
and it works with objects of varying sizes.  The small and varying size
objects usually cause trouble with other memory allocators. 

If it does this flip often enough the memory stays relatively compact.
If it does it too often if spends to much time copying. There are tricks
where you have multiple arenas that consist of different "generations"
of objects.  You let old objects that never change group together in one
arena and if during a flip cycle none of them ever changed then that
arena can be left alone with no copying required.

Of course there is a overhead of memory (up to a factor of two) due to
the fact that you need the old arena and the new at the same time.  This
is reduced if you have multiple generation arenas and the old isn't
copied.  So adding the generational enhancement improves both speed and
memory requirements.