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.
