[erlang-questions] Erlang and Memory management

[Jesper Louis Andersen]

On Wed, Jun 1, 2011 at 15:49, Michael Turner
<michael.eugene.turner@REDACTED> wrote:

> 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?

Also, you need a copy when you go to another distributed machine
anyway. So suddenly locality will play a role. From a point of
performance, locality matter.

> 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.

Garbage Collection will usually unfragment data anyway. But the
process heap acts as a crude region-based memory manager: When a
process dies, we can *instantly* reset its memory area and give it
back. And that kind of cleanup is really effective. This gives us a
region of memory of which we have some control, due to the lifetime of
the process. In a shared heap, you loose that control and have to wait
until the next GC for the memory to be reclaimed. The fact that you
can tune the GC of each process rather than for the whole VM is also a
pretty good thing.


-- 
J.