Thu Sep 2 13:23:24 CEST 1999
Bjorn Gustavsson writes:
> 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.
I know, this the situation in open source erlang as well.
However the message bugger queue is part of the root set and
can thus not be easily fiddled with if the process
is in an interupted gc state.
> 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).
Either that, or suspend the sender which is a whole lot
easier. I wrote "deadlocks ???" and I've thought a bit about
that now and I don't think it's an issue. ?? Think hard.
> > 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.
Yes, on the other hand one of the more common situations
for a process to get a really huge heap is that somebody
is bombarding it with messages and the process can't keep
up with the processing of all async messages.
If the sender is suspended, it changes that situation a bit.
An other question, what about distributed messages if the sender is
to be suspended. Set the dist port to blocked, thereby
inhibiting *all* dist messages on that port just because one
process is garbing ??
More information about the erlang-questions