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

[Francesco Cesarini]

When looking at the unified heap, one of my major worries is memory
fragmentation. Due to past experience (Jam 1998) after having run heavy duty
programs for a long period of time, I am scared it is bound to happen. Has
the Hipe team looked into this? Have you any theories or done any
measurements?

Regards,
Francesco

Per Bergqvist wrote:

> 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

--
http://www.erlang-consulting.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: francesco.vcf
Type: text/x-vcard
Size: 352 bytes
Desc: Card for Francesco Cesarini
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20011011/65afa2cb/attachment.vcf>