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

[Hynek Vychodil]

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
>   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.
>

+1
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...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080129/776454c8/attachment.htm>