Re:Erlang/OTP: Garbage Collector
by vcryan on Saturday April 01, 2023 @12:48PM
(#35401756)
Ha! Absolutely no
[ Parent
| on HN ]
Why not? JVM has a highly optimized concurrent GC.
Re:Erlang/OTP: Garbage Collector
by omginternets on Saturday April 01, 2023 @02:24PM
(#35402656)
It’s a GC tuned for imperative languages that prefer mutation over allocation, which is the exact inverse of what BEAM needs.
OpenJDK's GCs do have elaborate mechanisms to support mutation, but if they're unused they impose no extra overhead.
Re:Erlang/OTP: Garbage Collector
by omginternets on Saturday April 01, 2023 @10:44PM
(#35406622)
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.
Re:Erlang/OTP: Garbage Collector
by NobleExpress on Sunday April 02, 2023 @12:13AM
(#35407095)
Hm? G1 is a generational GC? And so is Serial/Parallel. And work on generational ZGC is ongoing [1]. Not sure what you're referring to here.
Re:Erlang/OTP: Garbage Collector
by omginternets on Sunday April 02, 2023 @05:31PM
(#35415462)
I was mistaken!
The JVM has a selection of four generational GCs. Two of them are the most sophisticated GCs available anywhere.
It's not a matter of some unique brilliance. Java is simply in such high demand that it has the sufficient resources to have state of the art optimising compilers and GCs.
Re:Erlang/OTP: Garbage Collector
by omginternets on Sunday April 02, 2023 @05:31PM
(#35415459)
Really? I had no idea. Can you suggest further reading?
Erlang has a highly optimized concurrent GC as well. It's just optimized for different things. And maybe the concurrency of the GC is different; Erlang has one heap per process (aka green thread), and no concurrency within a heap.
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.