[erlang-questions] Erlang's garbage collector
Sasa Juric
sasa.juric@REDACTED
Fri Aug 23 22:05:21 CEST 2013
Is there a document (other than the source code) where one can find out about the GC internals. Not low level details, but more a general characteristics.
In particular, I'm interested how Erlang GC profits from memory isolation. I've seen claims that it works on a process level. Does it mean it runs separately for each scheduler (allowing other schedulers to work)?
Since processes are isolated, is a process memory immediately reclaimed after the process terminates?
On Aug 22, 2013, at 11:04 PM, Jesper Louis Andersen wrote:
>
> On Thu, Aug 22, 2013 at 4:35 PM, Yves S. Garret <yoursurrogategod@REDACTED> wrote:
> Am I understanding this correctly? You have two heaps and if a piece of memory keeps getting
> referenced, it gets moved into the "old" heap and the "new" heap's memory gets freed up a little,
> yes?
>
> Well the heap is divided in two regions, old and young. New data is allocated on the young heap. When it fills, the young heap is garbage collected. Data which is dead is removed and data which is still live survives on the young heap. When it has survived enough times (3) then it is promoted to the old heap.
>
> The reason for this scheme is that you keep the young heap small and collect it often. Collection is faster in a small heap. Also, since most objects tend to be used only once at most, they are usually dead when the young heap collects. Objects which survive are usually long lived, so they get promoted into the old heap. It is then collected more rarely.
>
> The view here is simplified, but it might do.
> _______________________________________________
> 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/20130823/6e4f7fc6/attachment.htm>
More information about the erlang-questions
mailing list