Garbage collection

[Bjorn Gustavsson]

Klacke <klacke@REDACTED> 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 
> applied.

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.

/Bjorn Gustavsson