Garbage collection

[Klacke]

David Brown writes:
 > I would
 > guess that Boehm would probably not perform as well as the existing GC
 > in the Erlang runtime, since it always has to scan blocks for more
 > pointers.  We know out types and only have to descend objects that
 > might contain pointers. 
 > 

So would I, but as usual, speculating gets us nowhere. :-(

Another major difference in the runtime would also be
that all the copying of data that takes place in the
current runtime could (possibly) be replaced by copying
pointers instead !!

Today message passing, ets.erl lookups/insertions are done
by *copying* the data between the process heaps.

(The structure copying code is highly optimized
 (erts/system/emulator/runtime/copy.c) and as
 long as messages are reasonably small, the copying
 overhead vanishes among all the other things that's 
 happening.)
 

Robert Virding had a couple of different erlang implementations
a couple of years ago (called VEE) that were using a global
heap for all the erlang processes instead, none of his implementations
reached production status though.

All in all, doing a little Boehm hack might be pretty
interesting. 

We also need to keep in mind that the typical sort of 
applications that Erlang is intended for are supposed to
run without stopping for a very long time[*]. This implies that
GC is good way to go, but it also implies that *all* data
must be eventually collected. A conservative collector may
forget 10 bytes/hour which leads to a very very hard to find bug.
So performance is important, but complete correctness is even more so.

/klacke


[*] I once read that the third most frequent bug in 
    the Ericsson AXE switch was 32/16 bit counters that 
    overflowed. There's a lot of counters in a telephone
    switch :-)