[erlang-questions] effect of destructive updates on GC implementation
Tue Jan 29 22:42:19 CET 2008
On Jan 29, 2008 10:21 PM, Mikael Pettersson <mikpe@REDACTED> wrote:
> 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
> 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.
robustness, reliability, programmer productivity - It is why I like Erlang
without destructive updates. Performance is on second place.
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions