[erlang-questions] effect of destructive updates on GC implementation

[Mikael Pettersson]

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
   Java, thankfully.
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
   programmer productivity.
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
   passing.

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.