[micmus]

Erlang has a per-process GC - each Erlang process has it's own heap and it's own garbage collector. There's no VM-wide GC. This usually means the GC pauses apply only to a small part of your system, while the other parts are running completely normally. There's a good article that describes it in depth: https://www.erlang-solutions.com/blog/erlang-19-0-garbage-co...

[noss]

Also if you have a lot of data you use an ets table which is more or less an in-process but off-gc-heap key-value database.

[staticassertion]

Thanks, I've been wondering how Erlang does GC.

[AstralStorm]

Of course, the cost is extra heap fragmentation.

[dfox]

In Erlang case, that is not so much of a problem as most allocated objects have essentially same size. On the other hand this causes another problem that GC's and allocators in Erlang VMs tend to have enormous overhead because most most GC'd objects are very small with sizes comparable to per-object GC overhead.

[agumonkey]

I joked once that in lisp, a vast majority of memory allocation are basically malloc(2). I wondered if it made fragmentation irrelevant.