[erlang-bugs] http://www.erlang.org/faq/academic.html - section 10.23 with respect to shared heap needs correction?

[Joseph Wayne Norton]

I noticed the last statement of section 10.23 with respect to shared heap.  It seems this feature is no longer supported or is undocumented?  If it is still present, could you point me to the appropriate documentation?

regards,

Joe N.




http://www.erlang.org/faq/academic.html
10.23  How does the Garbage Collector work?

The current default GC is a "stop the world" generational mark-sweep collector. Each Erlang process has its own heap and these are collected individually, so although every process is stopped while GC happens for one processes, this stop time is expected to be short because each process is expected to have a small heap.

The GC for a new process is full-sweep. Once the process' live data grows above a certain size, the GC switches to a generational strategy. If the generational strategy reclaims less than a certain amount, the GC reverts to a full sweep. If the full sweep also fails to recover enough space, then the heap size is increased.

In practice, this works quite well. It scales well because larger systems tend to have more processes rather than (just) larger processes. Measurements in AXD301 (the large ATM switch) showed that about 5% of CPU time is spent garbage collecting.

Problems arise when the assumptions are violated, e.g. having processes with rapidly growing large heaps.

There are some alternative approaches to memory management which can be enabled at run-time, including a shared heap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121129/0c16d8ca/attachment.htm>