6 ms·

Erlang Garbage Collection Details and Why It Matters

66 points by yinso 9y ago

rdtsc 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
      - rdtsc 9y ago
        It is not completely different. Both Erlang and Rust emphasize safety at the top of their feature lists. That is contrast with most other languages / platforms.
        gens 9y ago
        It is COMPLETELY different from rust. Not only in the syntax, but also in the things it does and how it does them. http://learnyousomeerlang.com/content http://learnyousomeerlang.com/content A lot of languages "emphasize safety at the top of their feature lists". By a lot i mean A LOT. If you have to compare, Erlang is similar to Haskell. Rust is nothing like erlang.
        rdtsc 9y ago
        > COMPLETELY different from rust. Not only in the syntax Why bring syntax as the first thing? What does that have todo with memory safety. > By a lot i mean A LOT. You mentioned Haskell and Ada so far. Which I agree with. What are the other ones?
        gens 9y ago
        I also mentioned FORTRAN. A 10min investigation would bring fruit to your curiosity. But wth.. Lisp, scheme, closure, modula and smalltalk are the ones that come to my mind now that offer ONLY safe data access (modula3 has "unsafe" keyword, but only when talking to outside code). Actually R, awk, bc, shell and such are also like that, but not really general purpose. Languages that are "memory safe" by default, but include "unsafe" memory access (that come to my mind now) are C#, F#, C++ and such (Rust goes into this "category"). All functional languages are, AFAIK, "memory safe" by default (well.. you could make a functional language that lets you go out of bounds, but that wouldn't be a "pure" functional language). In fact, as far as i know, there are more programming languages that ARE "memory safe" then ones that are not. One could just go over the wikipedia list [0] and.. list them out. [0] https://en.wikipedia.org/wiki/List_of_programming_languages https://en.wikipedia.org/wiki/List_of_programming_languages While somewhat on the topic of functional vs "Turing" languages, here's a couple of videos. https://www.youtube.com/watch?v=eis11j_iGMs https://www.youtube.com/watch?v=eis11j_iGMs https://www.youtube.com/watch?v=RPQD7-AOjMI https://www.youtube.com/watch?v=RPQD7-AOjMI So.. the only thing that prompted you to talk about Rust is memory safety ? EDIT: > Why bring syntax as the first thing? What does that have todo with memory safety. Because the question i asked was "Can i ask why do you mention rust ? By that i mean what prompted you to write about rust here and now." and your answer was (paraphrased) "they bout emphasize memory safety", as if that was the only defining factor of a programming language.
  - rdtsc 9y ago
    Memory safety. I made the point that Erlang VM puts memory safety front and center by using isolated heaps. And from there made a comparison between operating systems and language platforms. In the end pointed out that Rust accomplishes memory safety as well but in a different way - via a compiler check.
- lyouk 9y ago
  These paid Rust shills are getting too obvious nowadays. Nobody is going to use Rust because of its political baggage and all that drama surrounding it.
  - auggierose 9y ago
    Loop me in, what baggage and what drama?
  - rdtsc 9y ago
    Heh, it is right on the border where half the people will consider this good sarcasm and the other half will consider it a disparaging comment.
  - sctb 9y ago
    Please don't violate the guidelines like this. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
jlouis 9y ago
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 9y ago
  > 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.
  - SEMW 9y ago
    Note that binaries >64 bytes are indeed stored in shared memory and reference counted. (Including utf8 strings (as opposed to charlists), which are binaries in erlang). See http://erlang.org/doc/efficiency_guide/binaryhandling.html#refc_binary http://erlang.org/doc/efficiency_guide/binaryhandling.html#r... for more info
  - jlouis 9y ago
    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.

66 points by yinso 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.
    - rdtsc 9y ago
      It is not completely different. Both Erlang and Rust emphasize safety at the top of their feature lists. That is contrast with most other languages / platforms.
      - gens 9y ago
        It is COMPLETELY different from rust. Not only in the syntax, but also in the things it does and how it does them. http://learnyousomeerlang.com/content http://learnyousomeerlang.com/content A lot of languages "emphasize safety at the top of their feature lists". By a lot i mean A LOT. If you have to compare, Erlang is similar to Haskell. Rust is nothing like erlang.
        rdtsc 9y ago
        > COMPLETELY different from rust. Not only in the syntax Why bring syntax as the first thing? What does that have todo with memory safety. > By a lot i mean A LOT. You mentioned Haskell and Ada so far. Which I agree with. What are the other ones?
        gens 9y ago
        I also mentioned FORTRAN. A 10min investigation would bring fruit to your curiosity. But wth.. Lisp, scheme, closure, modula and smalltalk are the ones that come to my mind now that offer ONLY safe data access (modula3 has "unsafe" keyword, but only when talking to outside code). Actually R, awk, bc, shell and such are also like that, but not really general purpose. Languages that are "memory safe" by default, but include "unsafe" memory access (that come to my mind now) are C#, F#, C++ and such (Rust goes into this "category"). All functional languages are, AFAIK, "memory safe" by default (well.. you could make a functional language that lets you go out of bounds, but that wouldn't be a "pure" functional language). In fact, as far as i know, there are more programming languages that ARE "memory safe" then ones that are not. One could just go over the wikipedia list [0] and.. list them out. [0] https://en.wikipedia.org/wiki/List_of_programming_languages https://en.wikipedia.org/wiki/List_of_programming_languages While somewhat on the topic of functional vs "Turing" languages, here's a couple of videos. https://www.youtube.com/watch?v=eis11j_iGMs https://www.youtube.com/watch?v=eis11j_iGMs https://www.youtube.com/watch?v=RPQD7-AOjMI https://www.youtube.com/watch?v=RPQD7-AOjMI So.. the only thing that prompted you to talk about Rust is memory safety ? EDIT: > Why bring syntax as the first thing? What does that have todo with memory safety. Because the question i asked was "Can i ask why do you mention rust ? By that i mean what prompted you to write about rust here and now." and your answer was (paraphrased) "they bout emphasize memory safety", as if that was the only defining factor of a programming language.
- rdtsc 9y ago
  Memory safety. I made the point that Erlang VM puts memory safety front and center by using isolated heaps. And from there made a comparison between operating systems and language platforms. In the end pointed out that Rust accomplishes memory safety as well but in a different way - via a compiler check.
lyouk 9y ago
These paid Rust shills are getting too obvious nowadays. Nobody is going to use Rust because of its political baggage and all that drama surrounding it.
- auggierose 9y ago
  Loop me in, what baggage and what drama?
- rdtsc 9y ago
  Heh, it is right on the border where half the people will consider this good sarcasm and the other half will consider it a disparaging comment.
- sctb 9y ago
  Please don't violate the guidelines like this. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

jlouis 9y ago

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 9y ago
> 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.
- SEMW 9y ago
  Note that binaries >64 bytes are indeed stored in shared memory and reference counted. (Including utf8 strings (as opposed to charlists), which are binaries in erlang). See http://erlang.org/doc/efficiency_guide/binaryhandling.html#refc_binary http://erlang.org/doc/efficiency_guide/binaryhandling.html#r... for more info
- jlouis 9y ago
  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.