7 ms·

The post glosses over the most important part of Erlang's GC: it collects process heaps separately. This transforms a hard problem (collecting a global heap wit

by dmpk2k 4y ago

The post glosses over the most important part of Erlang's GC: it collects process heaps separately. This transforms a hard problem (collecting a global heap with low latency despite concurrent mutators) to a _much_ simpler problem, at the price of more copying. Compare Java's G1 with Erlang's GC; the former hurts my head. For those problems that are amenable to Erlang's model, this is a fine solution. The only real improvement here would be making collection incremental.

weatherlight 4y ago
I thought Erlang's Garbage collector was incremental by virtue of being per process. A system may have tens of thousands of processes, using a gigabyte of memory overall, but if GC occurs in a process with a 20K heap, then the collector only touches that 20K and collection time is imperceptible. With lots of small processes, you can think of this as a truly incremental collector. It's not incremental per process, but I'm not sure it would even matter that much in practice.
- dmpk2k 4y ago
  Yes, that is how it works, except (as you implicitly note) that large heaps in single processes can cause problems; allowing incremental collection per heap would flatten the latency profile further.
- ramchip 4y ago
  Large GC jobs get scheduled on dirty schedulers today (a background thread pool), since it's not OK to block a normal scheduler more than 1ms or so in Erlang. If they could be split into smaller chunks of work, perhaps it could be done on normal schedulers, making time allocation more fair.
benmmurphy 4y ago
there are lots of foot guns for the user with this model. because transferring data between processes involves copying this can become a problem. Erlang tries to optimise the handling of large binaries by using a separate reference counted heap. however, this introduces another set of issues where memory is 'leaked' because a smaller binary is holding a reference to a larger binary or because processes that have not been GC'd have not decremented the ref count of large binaries in the heap that they no longer user.
- throwawaymaths 4y ago
  You literally listed the two biggest footguns and claimed there are "lots" of footguns. That really is it.
vkatsuba 4y ago
This is a good point, thanks! I will extend the topic or maybe will be better to provide new topic as continuation of the current topic - since putting everything in one article can be difficult to understand and will increase the article itself, making it more difficult to read.
_0w8t 4y ago
Erlang also has reference counters for things like strings that are immutable and can be shared between threads (processes in Erlang). Overall this is a good model. Use GC for small per green thread heaps. Then use reference counters for shared immutable structures that cannot form cycles and copy everything else.
- bitwalker 4y ago
  Erlang only uses reference counting for binaries larger than 64 bytes, everything else is allocated on the process heap (or in heap fragments) and copied. Just that is enough to have a beneficial effect though, since large binaries are relatively common in practice, and are frequently passed around from process-to-process.
  - derefr 4y ago
    And if you have any other global state you want to pass around, you can pull off a clever trick by passing it around as a binary and then unpacking it as needed within caller processes. AFAIK this trick is why BEAM files use an IFF-derived format (easy to parse individual chunks out at runtime), and why erlang:module_info/{1,2} are the way they are: working with module metadata literally just means asking the code-server process for the (shared refcounted) module binary, and then parsing it yourself.
amelius 4y ago
Wouldn't Erlang be much more efficient if it simply compiled to the JVM?
- lenkite 4y ago
  JVM standard does not support isolates so it won't work. Java's father Gosling wanted to get isolation into the Java spec but he failed. The modern GraalVM does have isolates but its a VM specific feature and not a java standard feature.
- nesarkvechnep 4y ago
  No.
- vcryan 4y ago
  Ha! Absolutely no
  - amelius 4y ago
    Why not? JVM has a highly optimized concurrent GC.
    - omginternets 4y ago
      It’s a GC tuned for imperative languages that prefer mutation over allocation, which is the exact inverse of what BEAM needs.
      - pron 4y ago
        OpenJDK's GCs do have elaborate mechanisms to support mutation, but if they're unused they impose no extra overhead.
        omginternets 4y ago
        I think you may be missing the point. What the JVM doesn't have is elaborate optimizations to support copies, e.g. a generational GC.
dfox 4y ago
Another point is that due to erlang's immutability there cannot be pointers from oldgen into nursery and thus the GC does not need write barriers.
throwawaymaths 4y ago
> the price of more copying. More copying if you pass values between processes. Honestly it would be really cool if you could mark off certain values that you know you're going to pass around and put them in a heap like the global binary heap.

by dmpk2k 4y ago

weatherlight 4y ago

I thought Erlang's Garbage collector was incremental by virtue of being per process. A system may have tens of thousands of processes, using a gigabyte of memory overall, but if GC occurs in a process with a 20K heap, then the collector only touches that 20K and collection time is imperceptible. With lots of small processes, you can think of this as a truly incremental collector. It's not incremental per process, but I'm not sure it would even matter that much in practice.

dmpk2k 4y ago
Yes, that is how it works, except (as you implicitly note) that large heaps in single processes can cause problems; allowing incremental collection per heap would flatten the latency profile further.
ramchip 4y ago
Large GC jobs get scheduled on dirty schedulers today (a background thread pool), since it's not OK to block a normal scheduler more than 1ms or so in Erlang. If they could be split into smaller chunks of work, perhaps it could be done on normal schedulers, making time allocation more fair.

benmmurphy 4y ago

there are lots of foot guns for the user with this model. because transferring data between processes involves copying this can become a problem. Erlang tries to optimise the handling of large binaries by using a separate reference counted heap. however, this introduces another set of issues where memory is 'leaked' because a smaller binary is holding a reference to a larger binary or because processes that have not been GC'd have not decremented the ref count of large binaries in the heap that they no longer user.

throwawaymaths 4y ago
You literally listed the two biggest footguns and claimed there are "lots" of footguns. That really is it.

vkatsuba 4y ago

This is a good point, thanks! I will extend the topic or maybe will be better to provide new topic as continuation of the current topic - since putting everything in one article can be difficult to understand and will increase the article itself, making it more difficult to read.

_0w8t 4y ago

Erlang also has reference counters for things like strings that are immutable and can be shared between threads (processes in Erlang). Overall this is a good model. Use GC for small per green thread heaps. Then use reference counters for shared immutable structures that cannot form cycles and copy everything else.

bitwalker 4y ago
Erlang only uses reference counting for binaries larger than 64 bytes, everything else is allocated on the process heap (or in heap fragments) and copied. Just that is enough to have a beneficial effect though, since large binaries are relatively common in practice, and are frequently passed around from process-to-process.
- derefr 4y ago
  And if you have any other global state you want to pass around, you can pull off a clever trick by passing it around as a binary and then unpacking it as needed within caller processes. AFAIK this trick is why BEAM files use an IFF-derived format (easy to parse individual chunks out at runtime), and why erlang:module_info/{1,2} are the way they are: working with module metadata literally just means asking the code-server process for the (shared refcounted) module binary, and then parsing it yourself.

amelius 4y ago

Wouldn't Erlang be much more efficient if it simply compiled to the JVM?

lenkite 4y ago
JVM standard does not support isolates so it won't work. Java's father Gosling wanted to get isolation into the Java spec but he failed. The modern GraalVM does have isolates but its a VM specific feature and not a java standard feature.
nesarkvechnep 4y ago
No.
vcryan 4y ago
Ha! Absolutely no
- amelius 4y ago
  Why not? JVM has a highly optimized concurrent GC.
  - omginternets 4y ago
    It’s a GC tuned for imperative languages that prefer mutation over allocation, which is the exact inverse of what BEAM needs.
    - pron 4y ago
      OpenJDK's GCs do have elaborate mechanisms to support mutation, but if they're unused they impose no extra overhead.
      - omginternets 4y ago
        I think you may be missing the point. What the JVM doesn't have is elaborate optimizations to support copies, e.g. a generational GC.

dfox 4y ago

Another point is that due to erlang's immutability there cannot be pointers from oldgen into nursery and thus the GC does not need write barriers.

throwawaymaths 4y ago

> the price of more copying. More copying if you pass values between processes. Honestly it would be really cool if you could mark off certain values that you know you're going to pass around and put them in a heap like the global binary heap.