Erlang 19.0 Garbage Collector | Hacker News Reader

Erlang 19.0 Garbage Collector

erlang-solutions.com

261 pointsbandris21 comments

Very well done article.

Release 19.0 is looking exciting, other things they seem to be planning on (this is mainly from Erlang Factory 2016 Slides):

* 10x faster tracing

* Dirty schedulers turned on by default

* A new state machine OTP module

* An external plugin (with LevelDB as one example) for Mnesia storage

* 2x-3x faster spawning external processes + many others

18.0 brought fast maps, good time handling. It is exciting to see all this good stuff done in a 30 year old language.

Erlang is getting cool new features so fast it's hard to keep up. It's a nice problem to have :)

Are there anything else? All these seems like working on even better parallelism and reducing overhead. I wonder if there are any work on BEAm for procedure / maths calculation processing.

Edit: Where is ErlangLLVM?

The Erlang garbage collector is a fascinating topic; here is a discussion on HN about it:

https://news.ycombinator.com/item?id=10218343

Sort of a meta note: it's interesting how some of the really technical articles get a ton of votes, but not many comments.

Very interesting in any case, and I certainly voted for it - I'd love to see more articles like this.

I get the impression that Erlang is one of those languages we all wish we had the time to really dive deep into but never will. Same as Rust. So it gets upvotes.

I used it at the last place I worked. It was a great fit for what we were doing (a semi-embedded device).

How embedded was "semi-embedded"? I ask because I'm on a project for which we had discussed using Erlang or Elixir but decided the VM overhead was too high to support all our uses.

Well, Erlang's been around for like 30 years. What was a pretty powerful computer back then is something we'd call "embedded" today. Of course, we still call things with 8-bit processors and single-digit kilobytes of RAM embedded, too. So it depends on where you fall in that scale. The phone switches it was designed to run are also fairly low-power devices by modern standards. (Lots and lots and LOTS of custom hardware, but not necessarily a lot of "CPU".)

In addition to what the article itself talks about, there's a number of other memory knobs you can twiddle for various use cases.

I apply that term more liberally, it not much as about size of CPU or RAM but more about how it is indented to be used.

Is the user expected to know about OS packages on it. Are they installing/updating software components by hand, so they know the OS version which runs in the box even, are they calling it a "server"? If the answer is yes, it not "embedded".

If they interact with the device as with an appliance (a dvd player, microwave, car infotainment center, some radio base station and so on), then it is embedded. It can still be an 8 core Xeon monster, but because of how it is serviced and used it, I think of it as embedded.

Once again, exactly: the device in question was not severely CPU or memory constrained or anything, but the user treated it more like an appliance than like a computer. Also had some real-time-ish stuff that was mostly handled in C++.

In many cases for example, the device hardware and software is structured in 2 layers -- control layer (called a plane also) and data layer. Erlang is usually sitting on the control layer, it manages things, authenticates connections, handles routing setup, handles failures, monitoring setup etc.

The data layer is usually hardware or C drivers which handle streaming data. This is simple and as basic as possible so it can be monitored and managed by the control layer.

> The data layer is usually hardware or C drivers which handle streaming data.

Yep, lower level stuff was done in C, managed and connected by Erlang, which also talks to Postgres.

Even as someone who uses it full time, this article was just very well written, like I commented already, it describes what happens now and some changes. But others probably opted for an upvote.

Because of the nature of discussion groups on the internet, often people end up commenting if they want to disagree or nitpick. If there is an upvote feature, they just use that and often don't leave an "yap, agree" comment. I try to leave those when possible with additional things I like to balance the discussion out a bit. Otherwise things often end up negative by default (especially painful to see when someone shares a project they worked on).

This is very exciting. We use Erlang in an embedded environment and 19.0 will be a valuable release for us.

I wonder if the remaining processes can keep running while one is collecting? It looks like when collection of the old generation is running, then all processes in the VM must first be stopped. That is a drag for concurrency.

Each Erlang process has its own heap that can be GC'd in parallel, plus a shared global heap.

Just for future people who see this: the shared binary heap is not garbage collected, it's reference counted. When the process heap is GC'ed any references to the binary heap that didn't survive GC will be removed and refcounts updated. (Also when a process exits, all the binary heap references will be updated)

hopefully opening unix sockets is also allowed in 19

You may want to use the procket library: https://github.com/msantos/procket/

I think they're deliberately excluded because they don't work on Windows.

Reply on news.ycombinator.com