Hacker News Reader

Comment by qohen | Hacker News Reader

I don't know how the Erlang GC works so I can't really comment on that

If you're interested, here are a few helpful blogposts on the subject:

- This is a pretty short and readable post, though it's a bit old (2008): "Garbage Collection in Erlang" [0]

- A more detailed (and recent -- 2015) blogpost: "Erlang Garbage Collection Details and Why It Matters" [1].

- And this is the most up-to-date description, from April 2016 concerning Erlang R19, by Lukas Larsson, who works on the Erlang VM -- it is long, but well-written and has nice illustrations [2].

[0] http://prog21.dadgum.com/16.html

[1] https://hamidreza-s.github.io/erlang%20garbage%20collection%...

[2] https://www.erlang-solutions.com/blog/erlang-19-0-garbage-co...

View on HN

Or, if you don't want to chase those blogposts down, here's the nutshell version, from reference [1]:

In order to explain current default Erlang’s GC mechanism concisely we can say; it is a Generational Copying garbage collection that runs inside each Erlang process private heap independently, and also a Reference Counting garbage collection occurs for global shared heap.

(To expand on that a little: each process has its own copy of everything that it needs -- if it needs something from another process, it'll get a copy in a message sent to its mailbox, so: no shared memory, links, etc.

This encapsulation means that when a process terminates, all its memory is instantly reclaimed -- no GC is required, since no other process can possibly be referencing any data in the process that's going away.

And, while a process is alive, there's per-process generational-copying GC, as mentioned.

However, for pragmatic reasons, items > 64 bytes are stored in a global heap and references to those items are passed used (i.e. to avoid sending large things around) -- that's where the ref-counting GC comes in).

Yes, this strong process isolation is one of the design decisions which leads to the ultimate success of Erlang/OTP as a telecom platform. Joe Armstrong's thesis has explicit explanation why JVM is not suitable for telecom-grade reliability (no matter what sales people would tell you).

Another principal design decision, which complements share-nothing architecture, is a pure functional language with single "assignment". This greatly simplified runtime and VM itself which leads to more controlled and predictable behavior, suitable for soft-realtime systems.

The concept of drivers is another one, but it is irrelevant to this discussion.

Thank you for the explanation. I will read the links as well. Even if I don't use it, the design of Erlang is an interesting topic to study.

Reply on news.ycombinator.com