
Erlang Garbage Collector - signa11
https://www.erlang-solutions.com/blog/erlang-garbage-collector.html
======
richdougherty
> Each Erlang process has its own stack and heap

This is one of the cool things about the Erlang VM. Each process (lightweight
thread) has its own heap! In other VMs threads can affect each other by
generating garbage and causing GC pauses. In Erlang even the heaps are
isolated.

~~~
weberc2
How valuable is the property that other threads' GCs won't stop your thread if
your thread bears its own full stop? It seems like a concurrent collector with
a very small STW phase would be preferable. Lastly, the lack of shared memory
certainly enables simpler GC schemes like this one, and it precludes all sorts
nefarious bugs, but it also makes efficient parallelism impossible in many
cases. Depending on your application, that may not be suitable.

~~~
hyperpape
These are good questions.

Concurrent compacting collectors are pretty tough however, and a single
process STW should be much faster than a global one, since it will be (at
worst) proportional in time to the per process heap size.

~~~
weberc2
I suppose it would need to be compacting; Go seems to get along okay without
compaction, presumably because it has value types?

~~~
aidenn0
Go has traded throughput for latency. The throughput of a semispace copying
collector is very high for most workloads, but can suffer latency issues.
There is literally zero cost to collecting garbage in the nursery with the
algorithm described in TFA (a nursery collection has a cost proportional only
to the live data), and the cost of allocating in the nursery is just
incrementing a single value. However eventually you need to collect the entire
heap, and it's still proportional to the size of the live data, which is
usually the majority of the heap (since you've already collected the nursery
at that point).

~~~
weberc2
Sorry, I'm confused. Is Go's GC the semispaced copying collector or the TFA?
Or neither? Or both?

~~~
aidenn0
TFA == "The Fine Article" so refers specifically to the Erlang Garbage
Collector.

"Semispace" is one term to refer to the family of garbage collectors that
Erlang's derives from. The heap is divided into two spaces, hence "semispace"

So Go's GC is neither. Go's gc is tuned for lower latencies, and that tends to
rule out moving collectors (there are ways of having incremental moving
collectors, but they complicate the runtime a bit).

~~~
weberc2
Ah, thanks for the information and clarification!

------
bandris
Last year's post updated for Erlang/OTP 20. This is the number one information
source on Erlang's garbage collection. Well written.

------
tabeth
Can someone more familiar with Erlang/Elixir say some drawbacks of BEAM? I'm
learning Elixir now and as I become more familiar it seems very difficult to
write buggy code.

If only it were typed, ah... (no, dialyzer doesn't count).

~~~
Thaxll
Drawbacks, well it's slower than other language ( Java, C#, Go ), it's not
typed, the deployment / process liveness mechanisms are now useless with
Kubernates / Docker that are better at doing that and language agnostic.

~~~
bluesnowmonkey
It _can_ be slow, or not. We wrote some serialization code in Elixir and Java,
and the Elixir version was a little faster. It's good at that.

On the other hand, I had some bit twiddling code that was 13x slower than C. I
know because I rewrote that section into C as a NIF and benchmarked. The nice
thing then was my overall 95% Elixir app became about as fast as a 100% C app.

~~~
rurban
Exactly, beam is a pretty slow and unoptimized VM, CPU wise.

Which is not so important, as their strength is eliminating IO waits and
context switches which are usually much costlier.

Their GC is top notch.

------
sushisource
Please, those who control this site, if you're reading - don't use medium grey
text with very light font weight on a a white background.

