3 ms·
An economic argument for GC instead of ARC/ORC. Commercial web application in Java. Java GC is concurrent, on other cpu cores than the cores processing custom
by DannyB2 6y ago
An economic argument for GC instead of ARC/ORC.
Commercial web application in Java. Java GC is concurrent, on other cpu cores than the cores processing customer requests. Modern GCs such as Red Hat's Shenandoah or Oracle's ZGC have 1 ms or lower pause times on heap sizes of terabytes (TB). Java 15 increased max heap size from 4 TB to 16 TB of memory.
Now the argument. A thread running on a cpu core which processes an incoming request has to earn enough to pay the economic dollar cost of the other threads that do GC on other cpu cores. But that thread processing the client request spends ZERO cpu cycles on memory management. No reference counting. Malloc is extremely fast as long as memory is available. (GC on other cores ensures this.) During or even after that thread has serviced a client request, GC will (later) "dispose" of the garbage that was allocated when servicing the client request.
Obviously, just from Java continuously occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right.
That said, I find Nim very interesting, and this is not a rant about Nim. I am skeptical of an alternative to real GC until it is proven to work, in a heavily multi threaded environment. And there is that economic argument of servicing client requests with no cpu cycles spent on memory management -- until AFTER the client request was fully serviced.
- judofyr 6y ago> Obviously, just from Java occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right. I'm not sure if this argument holds. Java's high memory usage is frequently cited as a downside of Java. GUI applications written in Java have a reputation of being memory-hungry, and I know plenty of people struggling with memory usage of server application (e.g. ElasticSearch). You will also find C/C++ on the same popularity lists… That said, I do agree that a tracing GC is a better solution (for most programs) than reference counting these days. The improvements in the pause times by the Java GCs are really impressive, and the throughput is great. One example would be ESBuild: The author created a prototype in both Rust and Go, and found that the Go version was faster allegedly because Rust ended up spending a lot of time deallocating [source: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284].
- cb321 6y agoThe default tracing Nim GC is capable of quarter-millisecond pause times while the new ARC/ORC stuff is more like single-digit microseconds: https://forum.nim-lang.org/t/5734 https://forum.nim-lang.org/t/5734
- DannyB2 6y agoThat is interesting.
- DannyB2 6y ago> Java's high memory usage I would rather optimize for performance and energy use at the cost of higher memory use. See recent SN: https://news.ycombinator.com/item?id=24642134 https://news.ycombinator.com/item?id=24642134 https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle... Memory is a one time capital cost and gets cheaper over time.
- imtringued 6y agoHigh memory usage forces you to only run one JVM process. If you need to do something that doesn't require a significant amount of memory you can't use Java at all.
- darthrupert 6y ago> Memory is a one time capital cost and gets cheaper over time. Except if you're operating in the cloud.
- pjmlp 6y agoTrue, yet not everyone is trying to be the next FAANG. Besides, plenty of GC enabled languages support value types and ways to do deterministic deallocation, use the tools Luke.
- moonchild 6y agoThe majority of all GC research goes to java and (primarily the hotspot) jvm. ZGC and kin are like the zfs of garbage collectors: insanely good, but also insanely complex and not readily replicable. It's not practical to expect somebody with fewer resources than oracle to create something similar. Reference-counting strategies are much easier to optimize; so if you have fewer resources available to throw at your compiler it's the way to go.
- pjmlp 6y agoYou mean tracing GC, as reference counting is still GC. Adding value types and deterministic deallocation doesn't require endless GC research and was already available in languages like Mesa/Cedar and Oberon, features that Nim also has anyway.
- moonchild 6y agoReference counting is still GC, but I stand by what I said that the majority of all GC research goes into java. The GP was talking about using a tracing GC—like java uses—in nim; which I argue against.
- pjmlp 6y agoWhich is why Java is getting value types, as that research has proven that there is only so much that automatic escape analysis is capable of. Bare bones tracing GC in Java were the state of the art like 25 years ago. Java GC's are powering quite some interesting stuff, one just needs to open their mind beyond OpenJDK. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/ https://www.aicas.com/wp/ Still eventually, even Java would enjoy the value types and determnistic destruction capablities of languages like D, or to go to the days before Java, languages like Modula-3 and Eiffel, which they should have paid more attention to for Java 1.0.