[erlang-questions] OOP in Erlang

Fred Hebert mononcqc@REDACTED
Wed Aug 11 15:59:01 CEST 2010


On Wed, Aug 11, 2010 at 8:44 AM, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

>
> There is one idea here I have been toying with. One problem of Erlangs
> memory model is that sending a large datastructure as a capability to
> another process, several megabytes in size, will mean a copy. In the
> default VM setup that is. But if you had a region into which it got
> allocated, then that region could safely be sent under a proof that
> the original process will not touch it anymore. It is possible to
> infer regions like these (See Tofte/Talpin and later
> Niss/Makholm/Henglein) but I would opt for a simpler variant with
> explicit mention of regions for starters. If the (albeit cumbersome)
> model of explicit region management can't work out, why have any hope
> for an automatic variant? There is also a tangent here with
> substructural type systems, linear types or uniqueness types in
> particular. A destructive update can be allowed if we can prove we are
> the only one holding a reference to the data.
>
> But unless such a system works out rahter clearly, it is not worth the
> hassle of adding. Practical usefulness is more important for Erlang -
> so it should be kept in a theoretic toy language first for play, fun,
> and profit.
>
> One interesting point of *always* copying data structures is that you need
to plan for small messages (as far as possible) whether you are on a single
node or in a distributed setting. Moving up from a [partially] shared memory
model to a fully isolated one when going distributed is likely going to have
its share of performance problems and might create a dissonance between
"what is acceptable locally" and "what is acceptable when distributed".

I believe forcing messages to always be copied (except for large binaries)
reinforce the transparency and predictability of distribution in Erlang, on
top of keeping it all conceptually simpler on all levels. I'm not sure I
would necessarily like to give up these
hard-to-notice-but-still-pretty-useful advantages for the sake of speed on
local nodes.


More information about the erlang-questions mailing list