Thu Sep 2 13:09:45 CEST 1999
Klacke <> writes:
> 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
Yes, I think keeping the performance is the real problem.
> 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" ??
Messages sent to a process are never put directly onto the heap
of the receiving process. (They used to be in older version of Erlang.)
Instead, each message is put into a separately allocated message
buffer outside the heap.
Therefore, this should not be a problem. But you make must take good
care to keep track of the state (size of data in messages and which
messages that are new and so on).
> (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.
That is a real problem.
More information about the erlang-questions