Unified heap (was: Re: R8B PRE-RELEASES)

[rv@REDACTED]

This discussion about unified heaps has made me happy.

I have been advocating unified heaps for the last 13 years and I have
always felt that the multiples heaps were a kludge to get reasonable
gc preformance, at least some of the time.  I have even done a few
Erlang implementations based on it, the results were promising but
more work was needed.  I could not get any support for the work,
however, so I was unable to keep up with Erlang development.

The really big boost was that message passing was _fast_!  _Always_!
You don't have to avoid many processes because you would be sending
large messages all the time.  Here you could send all the messages you
wanted to.  This did expose a misfeature in Erlang devlopment(*).

There are definitely problems in doing a good implementation.  The
HIPE groups claim that a stop-and-gc of the whole heap still gives
acceptable gc performance does not hold in real applications.
Especially if you use large ETS tables.  You have to be much more
cunning.  I had some incremental collectors with bounded time gc
breaks that that were truly non-disruptive, but there were problems.
I think that the final one based from 1995 on a modified version of a
gc scheme by Joe Armstrong and me was the way to go.  It was truly
scalable and handled things like collectable atom tables and (large)
constant data structures easily and efficiently.  I had an efficient
ETS extension which ran without any copying planned.

I don't think that it is possible to drop in a good, incremental gc
into a BEAM without any extra work.  There are many places where you
must "keep your tongue right in your mouth".  It is not difficult, but
you have to be aware.

Joes and my algorithm is described in IWMM'95 (International Workshop
on memory management).  If anybody is interested I'll explain my
extensions.

Anyway I hope the HIPE people (or someone else) can do more with this.

	Robert

(*) Erlang processes have slowly been getting heavier as more features
have been added to them.  My dream has always been to have extremely
light weight processes, in every respect, and then code new features
using extra processes.  It may not always be possible to do this.

P.S. I am not at Bluetail/Alteon/Nortel anymore, just using the mail
address.

Per Bergqvist <per@REDACTED> writes:
>I am also a believer in the unified heap (or rather any technique that
>avoids memory copying)
>both by gut feeling and experience.
>
>I have always seen great performance improvements in my code with such
>techniques (i.e. vee in
>the good old days/dark ages and unified heap) and but for some strange
>reason I seem to be
>rather lonely with such findings. The majority of the community seem to
>get less improvements.
>
>It probably has to do very much with design patterns. I think that the
>greatest thing with Erlang is that
>the low cost processes allows designs where you don't have to mix
>behaviours in processes.
>Instead you have many, many small and simple independent but cooperating
>processes.
>The code become much cleaner easier to understand.
>(I my opinion this really the core in why it is possible to build such
>great systems with Erlang.)
>>To avoid getting performance boosts with unified heap you probably need
>to avoid message
>passing and have few complex processes in your application.
>
>I think that nobody can argue unnecessary memory copying is of evil.
>(It is a performance killer for every system, it takes time, trash caches
>...)
>
>What should be discussed is garbage collection.
>The critic of schemes avoiding memory copying always seems to be that a
>good gc
>will be very very hard if not impossible.
>Is that really true ? I am not the man to answer.
>It is true that the current gc enables a smooth execution and it is quite
>uncommon with
>long time system stalls for gc.
>
>Comments anyone ?
>
>/Per
>