Live data from Hacker News

Z Garbage Collector: The Next Generation

inside.java

21–30 of 126 posts

Re: Z Garbage Collector: The Next Generation

#21
post #2

Crazy 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?

Java 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…

[deleted]

Re: Z Garbage Collector: The Next Generation

#22
post #2

Crazy 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?

Java is still slower than C in its memory management for many cases, so we can safely say that this is not a solved problem.

Re: Z Garbage Collector: The Next Generation

#24
post #2

Crazy 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?

Optimal 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.

Re: Z Garbage Collector: The Next Generation

#25
post #6

As 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.

I 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.

Re: Z Garbage Collector: The Next Generation

#26
post #2

Crazy 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?

It’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.

Hell, not even sorting algorithms are “solved”, even though they are more than half a century old.

Re: Z Garbage Collector: The Next Generation

#27
post #2

Crazy 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?

Java is still slower than C in its memory management for many cases, so we can safely say that this is not a solved problem.

Memory 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 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.

Re: Z Garbage Collector: The Next Generation

#28
post #2

Crazy 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?

Java is still slower than C in its memory management for many cases, so we can safely say that this is not a solved problem.

If 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”.

Re: Z Garbage Collector: The Next Generation

#29
post #2

Crazy 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?

GC 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/15196411576216576...

https://www.youtube.com/watch?v=OUZt0mo1xic

https://old.reddit.com/r/java/comments/udtdke/the_real_cost_...

https://old.reddit.com/r/ProgrammingLanguages/comments/udt2p...

https://news.ycombinator.com/item?id=31192261

* Low-latency, high-throughput garbage collection

https://twitter.com/stevemblackburn/status/15183861337467289...

https://www.youtube.com/watch?v=1TLmawuxHfY

https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d...

https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java...

https://news.ycombinator.com/item?id=31153434

Post reply on HN