[erlang-questions] Erlang and Memory management

Michael Turner michael.eugene.turner@REDACTED
Wed Jun 1 15:49:25 CEST 2011


"Shared heaps can scale well and eliminate the need to copy data on message
sends."

The advantages seem obvious, but ... with cache-per-core, there will be
copying anyway: into the core's data cache. Immutable data is nice, because
you don't have to worry so much cache coherence.  But how many CPU
architectures are mutability-aware, at least at the right level?

Copying a data structure is also an opportunity to construct a "fresh" data
structure that's relatively unfragmented. Lower fragmentation of data
structures would make cache fetches more efficient, and cache hits hits more
likely, for the receiver.

Probably most Erlang code would faster with a shared heap, but some code
might slow down -- maybe by a lot. Putting certain smarts in Send might
help: e.g., if the receiving process isn't ready to run, copy; if it is
ready, just pass the pointer to shared memory. I'm sure lots more strategies
might be devised. And I'm about equally sure they'll all have their own
limits and pitfalls.

-michael turner

On Wed, Jun 1, 2011 at 4:20 PM, Tony Arcieri <tony.arcieri@REDACTED> wrote:

> On Tue, May 31, 2011 at 5:01 PM, Jack Moffitt <jack@REDACTED> wrote:
>
>> Could you elaborate a bit on the reason why you'd prefer a shared
>> heap? I was under the impression that individual heaps were one of the
>> ways Erlang achieved soft real-time performance. Is CPU power enough
>> improved (or garbage collectors) since Erlang made that decision that
>> it's no longer worth it?
>
>
> Erlang has to copy terms whenever they're sent in a message, aside from the
> exceptions noted earlier regarding binaries. With a shared heap, sending
> messages could be done by reference instead of actually copying data between
> process heaps.
>
> There are realtime (and even hard realtime) garbage collectors in the Java
> world which use a shared heap. Azul systems with 768 cores and 500GB+ heaps
> managed to keep GC pauses in the 10-20ms range, albeit with hardware memory
> barriers. Perhaps commodity x64 chips will get them at some point in the
> future as the number of CPU cores continues to grow.
>
> Shared heaps can scale well and eliminate the need to copy data on message
> sends.
>
> --
> Tony Arcieri
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110601/e56c4c98/attachment.htm>


More information about the erlang-questions mailing list