Garbage collection and memory management in Erlang

Question

I want to know technical details about garbage collection (GC) and memory management in Erlang/OTP.

But, I cannot find on erlang.org and its documents.

Some ar

Answer 1

To classify things, lets define the memory layout and then talk about how GC works.

Memory Layout

In Erlang, each thread of execution is called a process. Each process has its own memory and that memory layout consists of three parts: Process Control Block, Stack and Heap.

• PCB: Process Control Block holds information like process identifier (PID), current status (running, waiting), its registered name, and other such info.

• Stack: It is a downward growing memory area which holds incoming and outgoing parameters, return addresses, local variables and temporary spaces for evaluating expressions.

• Heap: It is an upward growing memory area which holds process mailbox messages and compound terms. Binary terms which are larger than 64 bytes are NOT stored in process private heap. They are stored in a large Shared Heap which is accessible by all processes.

---

Garbage Collection

Currently Erlang uses a Generational garbage collection that runs inside each Erlang process private heap independently, and also a Reference Counting garbage collection occurs for global shared heap.

• Private Heap GC: It is generational, so divides the heap into two segments: young and old generations. Also there are two strategies for collecting; Generational (Minor) and Fullsweep (Major). The generational GC just collects the young heap, but fullsweep collect both young and old heap.

• Shared Heap GC: It is reference counting. Each object in shared heap (Refc) has a counter of references to it held by other objects (ProcBin) which are stored inside private heap of Erlang processes. If an object's reference counter reaches zero, the object has become inaccessible and will be destroyed.

---

To get more details and performance hints, just look at my article which is the source of the answer: Erlang Garbage Collection Details and Why It Matters

Answer 2

I don't know your background, but apart from the paper already pointed out by jj1bdx you can also give a chance to Jesper Wilhelmsson thesis.

BTW, if you want to monitor memory usage in Erlang to compare it to e.g. C++ you can check out:

• Erlang Instrument Module
• Erlang OS_MON Application

Hope this helps!

Answer 3

A reference paper for the algorithm: One Pass Real-Time Generational Mark-Sweep Garbage Collection (1995) by Joe Armstrong and Robert Virding in 1995 (at CiteSeerX)

Answer 4

Erlang has a few properties that make GC actually pretty easy.

1 - Every variable is immutable, so a variable can never point to a value that was created after it.

2 - Values are copied between Erlang processes, so the memory referenced in a process is almost always completely isolated.

Both of these (especially the latter) significantly limit the amount of the heap that the GC has to scan during a collection.

Erlang uses a copying GC. During a GC, the process is stopped then the live pointers are copied from the from-space to the to-space. I forget the exact percentages, but the heap will be increased if something like only 25% of the heap can be collected during a collection, and it will be decreased if 75% of the process heap can be collected. A collection is triggered when a process's heap becomes full.

The only exception is when it comes to large values that are sent to another process. These will be copied into a shared space and are reference counted. When a reference to a shared object is collected the count is decreased, when that count is 0 the object is freed. No attempts are made to handle fragmentation in the shared heap.

One interesting consequence of this is, for a shared object, the size of the shared object does not contribute to the calculated size of a process's heap, only the size of the reference does. That means, if you have a lot of large shared objects, your VM could run out of memory before a GC is triggered.

Most if this is taken from the talk Jesper Wilhelmsson gave at EUC2012.