Garbage collection

[Klacke]

David Gould writes:
 > I might be interested in working on this. I am curious to know what has
 > prevented this in the past, 


It's a bit hard, to make the gc non blocking ggc.c needs to rewritten
into a reentrant collector. This is a bit hard and it also makes
the collector a bit slower unless some real clever tricks are 
applied.

Furthermore, when a process has garbed and the garb was 
not finished (since it took too long time) and execution
was resumed instead, well then we have a fairly complex
situation. Imagine that we need to send a message to such 
a "half-garbed" process, we need to allocate som memory there
for the message. Where do we allocate that memory, hardly
on any of the heaps that are "half-garbed" ??

(Or do we suspend the sender !!!, deadlocks ???)

Thus the situation which lead to this "half-garb", was probably
that the live data was large. Interupting the gc of this
large data set leaves us with a whole lot of memory which
is not released. The original two heaps of the process as
well as the new heap we're garbing to. Three heaps.
If a message arrives at the process, we need to have yet
another memory area associated with the process where we
can put the message, four heaps !!.

Now then, at a later stage when we're garbing
this 4-heap process, we need to make this gc reentrant as  well
otherwise there's no point in the exercise at all.


Well, the above sounds just horrible, so some sound strategy must
be applied here, I don't know which though.

And last but not least, the process must be marked (and queued)
for gc as well so that we can finnish off any lingering half-garbed
processes when the system is idling, this is the easy part because 
here we can simply put the process on the run queue and mark it
for GC.

/klacke


Claes Wikström                          Tel: +46 (0)8 692 22 09
Bluetail AB                             Email: klacke@REDACTED
Hantverkargatan 78                      WWW: http://www.bluetail.com
SE-112 38 Stockholm, SWEDEN