13 ms·
Z Garbage Collector: The Next Generation
- nielsbot 3y agoCrazy to me that garbage collection systems are a subject of continual evolution and discussion. You'd think it would be "solved" by now... Or is that just in Java world?
- killingtime74 3y agoI'm not sure what "solved" would mean for GC. Can't there always be improvements in maintainability, pause duration, correctness, throughput etc. Many dimensions to continually improve on. Unless someone comes up with a no pause, no compute power no code fully correct GC?
- kanzenryu2 3y agoJava already has that GC, it's called Epsilon https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-...
- Alifatisk 3y agoEpsilon doesn't GC at all?
- deleted 3y ago[deleted]
- kaba0 3y agoI think it was a tongue in cheek reply, as it is indeed a no-code, no-pause, no-compute power GC that does eventually reclaim the garbage (at process exit).
- Alifatisk 3y agoCorrect me if I am wrong but does it really GC at all if you receive an OutOfMemoryError?
- kaba0 3y agoIt’s meant for short lived apps where you simply wouldn’t get OOM either way. I don’t know about an objective definition for what a GC is, one I quite like is “gives the illusion of infinite memory”, based on that it isn’t a GC. But there are also conservative GCs, RCs, etc, that fail different definitions also (leaving behind circular dependencies, having false positives, in reverse order), like in case of many things in CS, there isn’t an objective definition.
- Alifatisk 3y agoThank you for the explanation, I think I get it now!
- tsimionescu 3y agoTheoretically someone could perhaps one day discover the theoretically optimal GC algorithm, and someone else could write the TeX of GCs using that algorithm, and then perhaps we'd have the final GC. Extremely unlikely that such an algorithm exists of course, and even if it did, looking at sorting will quickly suggests that improvements will keep being found even if the best asymptotic complexity had been achieved.
- mike_hearn 3y agoThere are some dimensions yes, but I do wonder if GC research is starting to approach the point of being "solved" well enough that we'll see a drop in investment. Not yet, clearly, but approaching that territory. If you look at the very latest JVMs you have three GCs which a spread over throughput-optimized (parallel), a middle ground jack of all trades (g1), and latency-optimized (zgc). They're a lot more self configuring in the past, so no matter what needs your app has it's usually just one CLI switch to get something fairly optimal. But ZGC is going generational, at which point it will have significantly higher throughput than before. Also, all the JVM GCs can handle massive heaps these days (like, terabyte scale). So at that point the choice might become even simpler: just use ZGC all the time unless you can tolerate higher pauses and want to reclaim some CPU for the app, in which case go with parallel. And in many cases the right tradeoff between latency and performance could be inferred automatically from the frameworks and libraries that are on the classpath, meaning that for most apps even needing to make that choice could go away. If you have a GC that doesn't pause, can handle terabyte sized heaps, has great throughput, is largely or completely self-configuring, is portable, open source, supports dozens of languages and has clean code, there are really very few metrics left to optimize after that. It seems like HotSpot is nearly there, especially when combined with GraalVM for language support.
- _a_a_a_ 3y ago> If you have a GC that doesn't pause, can handle terabyte sized heaps, has great throughput, is largely or completely self-configuring, is portable, open source, supports dozens of languages and has clean code Yeah. If.
- mike_hearn 3y agoThat's basically ZGC Generational + GraalVM. So, code that's available now albeit you'd have to compile it from version control (graalvm stable releases don't support zgc yet, released zgc isn't generational yet). Give it another year or so and that'll be shipping out of the box in ordinary JVMs.
- 3y ago
- ignoramous 3y ago> Unless someone comes up with a no pause, no compute power no code fully correct GC? Functional programming languages can be: https://www.reddit.com/r/haskell/comments/d5d13i https://www.reddit.com/r/haskell/comments/d5d13i / https://archive.is/4iyaG https://archive.is/4iyaG
- stingraycharles 3y agoIt’s just as “solved” as regular memory allocators are for C/C++ — it’s constantly evolving, with many competing solutions. TBB, tcmalloc, jemalloc, mimalloc, etc etc etc. Memory management is hard, and in a world where memory sizes keep increasing, new techniques being developed is expected and perfectly normal.
- kaba0 3y agoHell, not even sorting algorithms are “solved”, even though they are more than half a century old.
- TylerE 3y agoTim sort, used in python, V8, Android, and Swift, was invented in this millennium.
- re-thc 3y agoAnd there are yet newer and faster sorting algorithms being implemented.
- vlovich123 3y agoNotably quadsort which if I’m remembering my etymology correctly has pdqsort, fluxsort, and glidesort as descendents
- matsemann 3y agoLots of things in CS are actually cyclic: RAM is expensive, implement swapping from HDD. RAM gets cheaper, load all data there and instead optimize your code for CPU. Data gets bigger, need to go back to swapping again. Suddenly we get SSDs and hard drive access is lots faster, invent something new but similar to the old stuff. And so it goes, the bottleneck is always moved.
- JoachimS 3y agoAnd also in system design, computer architecture and engineering. T. H. Meyer and I. E. Sutherland coined this generational behaviour the "Wheel or Reincarnation" in their paper "On the Design of Display Processors." IMHO a paper that is still well worth reading: http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...
- _a_a_a_ 3y agoNot an expert but bear in mind that there can't really be one single thing called a 'good' garbage collector, because the behaviour of the programs that produce the garbage can be hugely varied, and the garbage so produced can likewise be hugely varied, and how you want to recover it can depend on the platform you're running on (if embedded, you probably want reference counting the tight memory, in other circumstances you might be very happy just to leak everything and let the OS clean up at the end. Edit: yes, it's sometimes ok to leak). As somebody says elsewhere, it's multidimensional issue and a single dimensional garbage collector can't be a brilliant match for everything. The book "Garbage Collection" by Richard Jones, recently discussed on HN, is something I'd highly recommend you buy and read.
- Ygg2 3y agoDue to Rice theorem any interesting property of computer program can be solved by solving the halting problem.
- moonchild 3y agoThat's backwards. One proof of rice's theorem relies on the fact that, if you could decide any interesting property of programs in general, then you could solve the halting problem; it doesn't follow that, if you could solve the halting problem, then you could decide any interesting property. It happens to be true that, if you could solve the halting problem, then you could decide any interesting property of programs; but this is simply because the antecedent is false.
- Ygg2 3y ago> That's backwards. See Wikipedia entry for Rice theorem subsection proof by reduction from the halting problem. 1. Have intersting property solver (e.g. is input squared) 2. Convert solver to halting problem solver 3. Solver is undecidable So they are in some equatable/convertible.
- moonchild 3y agoBeing able to turn an interesting property solver into a halting problem solver is not the same thing as being able to turn a halting property solver into an interesting problem solver.
- Ygg2 3y agoMy claim or at least intent was you can solve interesting property solver like you can solve a halting problem. I.e. not in a satisfying way (no false negatives or false positives with unlimited iterations). You can solve it to some extent (e.g. does program terminate in X steps).
- UncleMeat 3y ago
- executesorder66 3y agoJava was released in 1995. I wonder if you have ever updated any software that came out before then? Surely you don't update your OS. Windows/Linux/Mac all came out before 1995, and must surely be "solved" by now. In fact you probably still use Windows 95. Surely Windows 98 or any later version can't be any better? What's crazy to me is the sort of cognitive dissonance that you must have to hold a view like that, and still apply software updates at all.
- deleted 3y ago[deleted]
- darthrupert 3y agoJava is still slower than C in its memory management for many cases, so we can safely say that this is not a solved problem.
- kryptiskt 3y agoMemory management for C is not itself a solved problem, not only is there a lot of performance to squeeze out of malloc itself (the benchmarks on https://github.com/microsoft/mimalloc https://github.com/microsoft/mimalloc exemplifies the variance between the implementations), but it's up to the programmer to implement memory management in the large in an efficient way, which is not an easy task. One sure mark of a slow C program is one with a ton of mallocs and frees strewn all over.
- kaba0 3y agoIf we can know exactly where a particular object’s lifetime ends, then indeed we can write more efficient programs than possible with a GC, but that in the general case is not something we can determine at compile time (Rust’s lifetimes are a strict subset of the general case). Anything more dynamic will require some “ad hoc, informally-specified, bug-ridden, slow implementation of a GC”.
- pron 3y agoRust also relies on a GC for the more dynamic lifetimes in Rust programs (reference counting), it just doesn't call it a GC, and while Rust's GC has a lower footprint than tracing GCs, it has worse performance and it suffers from cycle problems. I wouldn't call it "bug ridden" (perhaps "limited" is a better term), but it is slow. Some think that reference counting gives better performance predictability than a tracing GC, but that is no longer true, certainly compared to the generational ZGC presented here. If you could determine the time where the collection would take place with a refcounting GC, i.e. when the last reference is cleared, you wouldn't need a refcounting GC. It is unpredictable pretty much by definition.
- kaba0 3y agoThat last line was just a play on this ( https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule ), but you are right of course.
- dwaite 3y agoOptimal memory behavior and lifetime is highly application specific, so the behavior of an automatic system likewise will be better for some applications than others. In Java, the goal is to have something that performs reasonably well, without degenerative cases, for a wide variety of applications and services. It also has to handle cases where a monolithic code base results in a multitude of different memory behaviors. Even thinking too hard on the ideal behavior will negatively impact application code. The research field of garbage collectors is a study of trade-offs. A highly tuned, application-specific memory strategy will likely outperform Java, but the goal is to not require anyone to build such a thing for most software.
- sideeffffect 3y agoGC is by no way a solved thing. Let alone in Java! Consider these developments: * Distilling the Real Cost of Production Garbage Collectors https://twitter.com/stevemblackburn/status/1519641157621657600 https://twitter.com/stevemblackburn/status/15196411576216576... https://www.youtube.com/watch?v=OUZt0mo1xic https://www.youtube.com/watch?v=OUZt0mo1xic https://old.reddit.com/r/java/comments/udtdke/the_real_cost_of_production_garbage_collector/ https://old.reddit.com/r/java/comments/udtdke/the_real_cost_... https://old.reddit.com/r/ProgrammingLanguages/comments/udt2pf/distilling_the_real_cost_of_production_garbage/ https://old.reddit.com/r/ProgrammingLanguages/comments/udt2p... https://news.ycombinator.com/item?id=31192261 https://news.ycombinator.com/item?id=31192261 * Low-latency, high-throughput garbage collection https://twitter.com/stevemblackburn/status/1518386133746728960 https://twitter.com/stevemblackburn/status/15183861337467289... https://www.youtube.com/watch?v=1TLmawuxHfY https://www.youtube.com/watch?v=1TLmawuxHfY https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d8/lowlatency_highthroughput_garbage_collection/ https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d... https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java_gc/ https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java... https://news.ycombinator.com/item?id=31153434 https://news.ycombinator.com/item?id=31153434
- datadeft 3y agoSince garbage collection based memory models are mush more complex and require a lot of software engineering it is not a surprise that we have many iterations.
- Jeff_Brown 3y agoThe name is a little misleading because once you know it's garbage, "collection" is trivial. The trick is to figure out what is garbage cheaply.
- ackfoobar 3y ago> You'd think it would be "solved" by now This can be an interesting inqury. Sad that you have to ruin it with snark. I guess in some sense it was "solved" more than a decade ago in Azul's C4 (Continuously Concurrent Compacting Collector). I wonder how a generational ZGC will compare against it.
- nielsbot 3y agoNo snark intended actually
- nayuki 3y ago> You'd think it would be "solved" by now... Or is that just in Java world? I'm not sure what you mean but I'll try to relate. Automatic garbage collection is a problem not just in the Java world. It's also needed in JavaScript, Python, Go, Haskell, etc. Citation needed, but I suspect the Java Virtual Machine ecosystem has the most advanced GC algorithms in the world. Even if that's not true, I can tell you with certainty that other language environments have adopted features many years after Java did, such as JavaScript V8 introducing concurrent generational copying in year 2017 ( https://v8.dev/blog/orinoco-parallel-scavenger https://v8.dev/blog/orinoco-parallel-scavenger ). I'm sure there are examples in Go as well where their GC implemented features that Java had a decade earlier.
- kaba0 3y agoThe JVM is definitely the state of the art when it comes to GC algorithms.
- nielsbot 3y agoPeople seem to think I was being snarky here, but I wasn't. It was honest surprise.
- jwr 3y agoAs a Clojure programmer, I'm so happy that I'm getting all these improvements over many years. It's fashionable to complain about Java — but I don't use Java, and yet I benefit from all the fantastic work that is being done on the JVM.
- pjmlp 3y agoThat is the positive attitude, it always irks me when guest language comunities bash the platform that make their language even possible in first place. Everything sucks, but then they gladly take the platform, the ecosystem of libraries, debuggers and what not from the host platform.
- nickpeterson 3y agoIt depends, some languages have more to complain about than others. I’d argue F# on .net basically had to spend years treading water while Microsoft’s various teams figured out .net core/framework. The community feels like it lost a lot of inertia it used to have.
- NeutralForest 3y agoI feel that the latest JVM developments have really been aimed at the developers: easier syntax, nice threading support, fast garbage collector, etc. On the GUI side I know that JavaFX has also been pushing for more features and more performance to become competitive again.
- millerm 3y agoI say this all the time to people that say they want to use Node because they hate Java. There are so many languages that you can execute on the JVM. It’s almost unfortunate that it’s still called the JVM. It think the JVM needs a re-branding. Even if they just change the meaning of the J. I suppose that is what GraalVM is doing, but it’s an awful name and its purpose isn’t being conveyed well. The JDK should just switch to this VM and get rid of the name JVM. These are just my opinions.
- 3y ago
- visarga 3y agoThis title is a perfect adversarial example for text classification. Contains both "Z" and "generation" in it but has nothing to do with Gen Z.
- re-thc 3y agoAnd Java has nothing to do with the island called Java. Javascript is not Java either. Hm. It's fine.
- capableweb 3y agoIf the logo didn't already made it clear which Java inspired the name, the island Java was/is also instrumental when it comes to growing coffee, so still, Java the language was a bit inspired by the island Java :)
- kookamamie 3y ago[flagged]
- WantonQuantum 3y agoNote that the Z Garbage Collector was released in JVM 11 so it’s about 5 years old now.
- pron 3y agoYes, but generational ZGC (https://openjdk.org/jeps/439 https://openjdk.org/jeps/439) has not been released yet. Possibly in JDK 21 this September.
- re-thc 3y agoMight have been easier calling it ZGC 2.0
- krylon 3y agoIf it's generational, ZGC Junior would be more appropriate. ZGC II, maybe. (SCNR)
- Gravityloss 3y agoZGCson? Easy to pronounce too!
- kaba0 3y agoZGC, Gen Z
- nicktelford 3y agoThe improvement in throughput is tantalising. I'd love to see a comparison to the G1GC throughput. I wonder if it's getting close enough that ZGC might some day become a candidate to replace G1 as the default collector?
- capableweb 3y agoAs far as I know, ZGC uses a lot memory than G1, and for as long that's the situation, it's unlikely to replace G1 as a default configuration. Another understanding I have is that ZGC is best used for large workloads, compared to G1 which is more generalized and doesn't perform as well with larger workloads. But, I'm no JVM experts and might have understood it incorrectly. Happy to be corrected!
- pwagland 3y agoYes, on small heaps you are still forced to use a 64bit pointer instead of a 32bit pointer, which means that your per-object overhead is higher, this means that on "normal" heap sizes, < 32Gb, you end up paying a reasonable penalty. That said, for a lot of use cases, this is still a reasonable trade-off to make, but it probably won't be promoted to "standard" until it's better in all use cases.
- tkot 3y agoWouldn't UseCompressedOops flag alleviate the issue for smaller heaps?
- aseipp 3y agoZGC relies on the space of 64-bit pointer (and the size of the 64-bit virtual address space) for its pointer coloring algorithm, and so it is by definition incompatible with UseCompressedOops even at small sizes. I suppose it's possible to fix this with a change to the design in some way. But if you have a heap smaller than 32GB, the existing G1 would probably work well too. ZGC shines much more on very large heap sizes since that's where long tail GC latency often hits hardest.
- ogogmad 3y agoIs the next generation of GCs going to use Reinforcement Learning and Machine Learning? The problem with a lot GC is that there's a currently unavoidable tradeoff between memory usage, latency and throughput.
- celeritascelery 3y agoHow would machine learning help balance those trade-offs?
- slavboj 3y agoPredicting memory usage patterns can help allocation strategy - eg if you get a flood of traffic every day at 9AM you can time GC to run before the rush, and efficiently preallocate space for the objects you predict needing.
- vips7L 3y agoLove ZGC's autotuning, I'm hoping for the day where we don't need -Xmx as well!
- nayuki 3y agoIt seems ZGC's autotuning is following in the footsteps of Azul's proprietary C4 (Continuously Concurrent Compacting Collector) which came a decade or two earlier. Both GCs are low-latency and their main tuning option is just the heap size.