[erlang-questions] effect of destructive updates on GC implementation
Tue Jan 29 22:21:01 CET 2008
Jonathan Amsterdam writes:
[GC 101 omitted]
> I haven't looked at the code for the Erlang GC, so I don't know how
> amenable it is to these changes. I just wanted to dispel some of the
> fear I imagine I hear when people intone "write barrier." Or maybe I
> am missing something, in which case I would appreciate being educated.
The core Erlang developers are well aware of the techniques
needed to support destructive updates in GC:d heaps.
There are however several other issues to consider:
1. Adding write-barriers/remembered-sets or their equivalent
to the GC would complicate an already complicated and
delicate part of the runtime system, which is not always
a win if you're aiming for five-nines robustness.
The runtime cost of the write-barrier is a non-issue,
since writes can be expected to be rare. Erlang is not
2. As soon as destructive updates are supported, people
will use them. From what I've heard from Ericsson folks,
the lack of destructive updates is actually a positive
thing for them, presumably due to program reliability and
3. The combination of message passing and mutable data breaks
the semantics of Erlang, or that of mutable data, and limits
the choices the Erlang implementors can make. Suppose P1
sends a term T to P2. P2 inspects it. Later, P1 updates
some part of T. Should P2 observe that change?
- if yes, the semantics of Erlang is now fundamentally altered,
- if no, the semantics of mutable data is severely restricted.
Furthermore, each choice creates new hard constraints on how
the runtime system may implement process heaps and message
So the real question is not whether adding updateable terms to
Erlang is possible (several people could do it, myself included),
but whether it's desirable. And on the whole, I think Erlang is
better off without them.
More information about the erlang-questions