4 ms·

Erlang: no global pause at all. Even for major GCs. Basically every Erlang process (≈ “green thread” in common terminology) has its own collector.

by lelf 7y ago

pron 7y ago
Yeah, but Erlang is very, very (very!) slow. And it, too, has shared data structures like ETS, which aren't so efficiently memory-managed.
- lelf 7y ago
  [citation needed]. I’d say it’s pretty freaking fast for a bytecode interpreter. Not to mention Hipe.
  - pron 7y ago
    https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ It's pretty bad. We're talking 3-20x slower than Java. FWIW, you can also look at the benchmark shootout game. Erlang/HiPE/BEAM is very cool, but it's just slooooooooow. Now, I'm not trying to say that OpenJDK is "better" than BEAM -- it's a great VM and it's good for lots of stuff -- but comparing performance-related features with Java doesn't make much sense, but it's not really in the same game. Yes, Erlang never has STW pauses, but you'll still get lower latency (and much higher throughput) with OpenJDK and ZGC or Shenandoah, despite the shared heap and occasional (short) STW pauses.
mcguire 7y ago
... which is why Erlang copies the contents of messages between actors. Pony uses a similar heap-per-actor, doesn't copy data, and uses background messages to update GC state between actors. Trade-offs.
ksec 7y ago
I assume ( may be wrong ) Project Loom achieves similar benefits when its lands on JVM.
- dymk 7y ago
  Erlang gets away with no global pauses because there is no shared state [1] between Erlang processes (their term for fiber). Loom/JVM fibers doesn't impose the same limitation; references can be shared across threads. So I would expect that, without a concurrent collector, you'd encounter global pauses. [1] outside of some special case, natively implemented datastructures
jamii 7y ago
But the per-process gc is pretty slow, and stw pauses are still proportional to the size of the working set in that process. If you have a multi-gb data-set you have to choose between a single process with long pauses, or spreading the data across multiple processes and paying for copying, locking and cache contention. Not to mention the extra code complexity of speading operations on single data-structure across multiple asynchronous sections. In many cases, for large working sets you're still better off with one the JVM GCs.

Erlang: no global pause at all. Even for major GCs. Basically every Erlang process (≈ “green thread” in common terminology) has its own collector.

by lelf 7y ago

Erlang: no global pause at all. Even for major GCs. Basically every Erlang process (≈ “green thread” in common terminology) has its own collector.

pron 7y ago

Yeah, but Erlang is very, very (very!) slow. And it, too, has shared data structures like ETS, which aren't so efficiently memory-managed.

lelf 7y ago
[citation needed]. I’d say it’s pretty freaking fast for a bytecode interpreter. Not to mention Hipe.
- pron 7y ago
  https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ It's pretty bad. We're talking 3-20x slower than Java. FWIW, you can also look at the benchmark shootout game. Erlang/HiPE/BEAM is very cool, but it's just slooooooooow. Now, I'm not trying to say that OpenJDK is "better" than BEAM -- it's a great VM and it's good for lots of stuff -- but comparing performance-related features with Java doesn't make much sense, but it's not really in the same game. Yes, Erlang never has STW pauses, but you'll still get lower latency (and much higher throughput) with OpenJDK and ZGC or Shenandoah, despite the shared heap and occasional (short) STW pauses.

mcguire 7y ago

... which is why Erlang copies the contents of messages between actors. Pony uses a similar heap-per-actor, doesn't copy data, and uses background messages to update GC state between actors. Trade-offs.

ksec 7y ago

I assume ( may be wrong ) Project Loom achieves similar benefits when its lands on JVM.

dymk 7y ago
Erlang gets away with no global pauses because there is no shared state [1] between Erlang processes (their term for fiber). Loom/JVM fibers doesn't impose the same limitation; references can be shared across threads. So I would expect that, without a concurrent collector, you'd encounter global pauses. [1] outside of some special case, natively implemented datastructures

jamii 7y ago

But the per-process gc is pretty slow, and stw pauses are still proportional to the size of the working set in that process. If you have a multi-gb data-set you have to choose between a single process with long pauses, or spreading the data across multiple processes and paying for copying, locking and cache contention. Not to mention the extra code complexity of speading operations on single data-structure across multiple asynchronous sections. In many cases, for large working sets you're still better off with one the JVM GCs.