
Erlang Garbage Collection Details and Why It Matters - yinso
https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
======
rdtsc
Very nice article. Good resource for memory handling in Erlang.

There is recent config setting since 19.0 to move the message queue outside
the main process heap. I have seen decent performance gains from that.

Sometimes for fun I like to describe a running Erlang VM as a modern os -
processes have isolated heaps and can be gc-ed independently. Then think about
programing in a language with a shared heap and it is a bit like putting that
mission critical code to run on Windows 95. You wouldn't do that in 2017, but
somehow we still do it at the language level.

Now Rust lets us have both speed and memory safety and it allows these
guarantees to happen at compile time. I think that is one of the more exciting
latest development in programming languages.

~~~
gens
Can i ask why do you mention rust ? By that i mean what prompted you to write
about rust here and now.

~~~
im_down_w_otp
I assume because of the correlation (s)he is drawing between memory safety
facilities that lend themselves to reliable, long-running software, and that
the next-generation of such software might be written in Rust based on those
facilities being at compile time?

Though in this context---if we were to include more than that one dimension of
the memory model---pony-lang seems like it might be the more Rust-like w/
compile time guarantees, but with a general programming model of
intercommunicating asynchronous processes included.

~~~
gens
Erlang is completely different then rust (or C, Ada, FORTRAN).

Why, on a topic about (an amazing language that is) erlang would you talk
about other languages. Especially when they are nothing like erlang.

~~~
im_down_w_otp
The majority of the post was about a cool/interesting way Erlang does
something and praising the linked article.

The very last statement was a passing commentary about something that seemed
conceptually correlated to the commenter.

I'm really confused by the hyper-sensitivity. With the exception of Javascript
conversation threads--- where they're overwhelmed by React vs. X---almost all
other language focused threads on HN are full of people making comparison and
contrast statements to different things.

~~~
gens
If i went into every thread about rust and mentioned how Ada is great (or any
other language, including C), id' get downvoted. Why is that ? "Hyper-
sensitivity" ?

~~~
Jtsummers
I've not done that in _every_ thread on Rust, but I have made similar comments
in Rust threads about areas where Ada has it beat with regard to some parts of
the type system and compile-time guarantees and checks. If I was ever
downvoted, it was not below base post karma (1).

------
jlouis
Best Erlang design decision: copying messages between process heaps.

Con: a small performance cost. Pro: a _far_ simpler system in every other
aspect. Garbage Collection and ownership is much easier when you are making
copies of data.

~~~
amelius
> Con: a small performance cost.

That entirely depends on the amount of data that needs to be copied (!)

In many cases, it pays off to actually use that intricate shared memory system
when possible. Yes, you lose some predictability, but you gain a lot of
performance.

~~~
jlouis
In Erlang programs, the amount of data to be copied tends to be rather small.
You'd much rather bring the computation to the data than sending the data
around for computation.

If you are storing a lot of data, you either tend to keep it in ETS, which has
its own storage engine (and you copy the small parts of data you work on
in/out of the ETS system), or as binary data, which are tracked by an ARC-like
system in its own arena/heap.

Of course, if you systematically abuse the system and ask it to copy several
megabytes around all the time, your efficiency will suffer. But note that this
is bad form: yes, it is faster locally internally inside a given node, but
once you start running true distribution, you don't want to copy megabytes of
data between nodes anyway.

Shared memory tend to imply a lot of locks, which can bring a lot of
contention as well. It is far more complex than just a general rule which says
"copying is always bad". And this was my main point, more or less. It is a
mistake to see copying for all its bad behaviour, without ever wondering what
it brings to the table as a result.

~~~
amelius
I'm not saying copying is always bad. I'm saying that there are cases where
you really want sharing, and therefore your language should allow it.

