Garbage collection

[David Gould]

On Thu, Sep 02, 1999 at 11:25:35AM -0500, James Hague wrote:
> On Thu, 2 Sep 1999, David Brown wrote:
> > 
> > Their collector is single threaded, and single heaped.  Moving to this
> > model might help with efficiency, since we could avoid the copy when
> > sending local messages.  The collector just needs to be run
> > periodically (easy with an interpreter) and only needs to be informed
> > about mutations.  It also eliminates issues with allocation in a
> > process whose GC would be running.
> 
> A nice benefit of a separate heap per process is that you can just throw
> out all the data for that process when it's killed.  Sharing a single heap
> would potentially result in more frequent collections.

This should not be a problem for a global heap garbage collector. Real
programs do not allocate memory in a steady way or even in any kind of random
distribution. They tend to have strong "phase" behaviour, allocating large
numbers of similar objects, working for bit, and then freeing most of the
previous allocations and allocating some new kind of object.

So any realistic memory manager has to cope with this kind of thing. Process
deallocation is just one kind of bursty allocator/collector workload.

-dg

-- 
David Gould           dg@REDACTED            510.628.3783 or 510.305.9468 
Informix Software                       300 Lakeside Drive  Oakland, CA 94612
You will cooperate with Microsoft, for the good of Microsoft
and for your own survival.                 -- Navindra Umanee