Thu Sep 2 11:22:52 CEST 1999
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
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
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
More information about the erlang-questions