<p dir="ltr"><br>
Den 23/08/2013 23.23 skrev "Sasa Juric" <<a href="mailto:sasa.juric@gmail.com">sasa.juric@gmail.com</a>>:<br>
><br>
> 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.<br>
> 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)?<br>

Yes. It runs as part of a process's timeslice - when the process runs out of free heap space.<br>
Other schedulers won't be doing anything with the heap of the process anyway, and can carry on without even being notified of the GC taking place. Isolation is indeed beneficial here.</p>
<p dir="ltr">> Since processes are isolated, is a process memory immediately reclaimed after the process terminates?<br>
Yes. Heap and stack memory, the message queue, and other resources such as ports and tables are released when the process disappears. (It's not atomic, of course - a process can afaik be "terminated" for a short while before it's also "cleaned up after", but that's typically not of importance.)<br>
</p>
<p dir="ltr">> On Aug 22, 2013, at 11:04 PM, Jesper Louis Andersen wrote:<br>
><br>
>><br>
>> On Thu, Aug 22, 2013 at 4:35 PM, Yves S. Garret <<a href="mailto:yoursurrogategod@gmail.com">yoursurrogategod@gmail.com</a>> wrote:<br>
>>><br>
>>> Am I understanding this correctly?  You have two heaps and if a piece of memory keeps getting <br>
>>> referenced, it gets moved into the "old" heap and the "new" heap's memory gets freed up a little, <br>
>>> yes?<br>
>><br>
>><br>
>> 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.<br>

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

>><br>
>> The view here is simplified, but it might do.<br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
</p>