11–20 of 79 posts
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 i…
Wouldn't Erlang be much more efficient if it simply compiled to the JVM?
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 i…
Wouldn't Erlang be much more efficient if it simply compiled to the JVM?
Scaling up an MQTT webhook relay that I wrote in Elixir to 1000’s of long running connections, I found that I needed to manually trigger periodic GCs on my long lived processes. As binary strings work their way through the pipelines via messages, it leaves binaries on the binary heap that don’t go away because the ref count stays above 1. There are a number of GC parameters one can tune on a per process level that mi…
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 i…
Wouldn't Erlang be much more efficient if it simply compiled to the JVM?
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 i…
Wouldn't Erlang be much more efficient if it simply compiled to the JVM?
The modern GraalVM does have isolates but its a VM specific feature and not a java standard feature.
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 i…
Earlier quoted context omitted.
Ha! Absolutely no
Why not? JVM has a highly optimized concurrent GC.
Erlang GC is also very simple and easy to understand because language features only allow references in one direction. Much of JVM GC complexity would be wasted as there's no need to look for reference loops and such, since they're not possible.
Scaling up an MQTT webhook relay that I wrote in Elixir to 1000’s of long running connections, I found that I needed to manually trigger periodic GCs on my long lived processes. As binary strings work their way through the pipelines via messages, it leaves binaries on the binary heap that don’t go away because the ref count stays above 1. There are a number of GC parameters one can tune on a per process level that mi…