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

[Robert Virding]

On 29/01/2008, Jonathan Amsterdam <jbamsterdam@REDACTED> wrote:
>
> > The core Erlang developers are well aware of the techniques
> > needed to support destructive updates in GC:d heaps.
>
> Apologies if my tone came across as patronizing. I just wanted to
> explain my position without assuming anything.
>
> > 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.
>
> This is something I've wondered about. Are there any
> production-quality, scalable programs that do not use mnesia, d/ets
> tables or process dictionaries?  That would be cool, but it seems to
> me that when you're dealing with huge amounts of real-world data that
> can change, the copying involved in purely functional data structures
> would kill you.


Of these three only process dictionaries come across as being fundamentally
mutable data structures, and then only in a limited way. Mnesia is based on
ets. While ets may seem like a mutable data structure (again in the limited
way like process dictionaries) they can actually be modeled, and
implemented, as processes. You don't actually create messages today and send
them, by copying in the BEAM, but you do the copying bit. Ets tables also
have a lot of the process semantics as well. If  table ids were pids then
you would be there. Think of being able to do operations directly on tables
on other nodes. :-)

As to whether the copying kills you there is only one way to find out and
that is to measure.

> 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.
> >
>
> This is the most compelling reason, for me.


I think there would be great semantic problems in adding  mutable data
structures to a system which does not have them. If you allow the the
mutating to reach between processes then you have added a "feature" which
distinguishes between local and remote processes. There are very few such
"features" today which I think is a VERY Good Thing. They cause problems in
that programs which work suddenly don't work because someone moved a process
to another node without knowing that somewhere deep inside there happened to
be some sharing. We might as well add locks, mutexes and synchronisation
primitives.

I am still unclear as to what problem you are actually trying to solve.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080203/3087e951/attachment.htm>