Live data from Hacker News

Z Garbage Collector: The Next Generation

inside.java

61–70 of 126 posts

Re: Z Garbage Collector: The Next Generation

#61
post #39

Earlier quoted context omitted.

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

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

My 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).

Re: Z Garbage Collector: The Next Generation

#62
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.

Is it still fashionable to bash Java? I remember the bashing of Java around 15 years or so ago, IMO justifiably because it could be slow to the point of making programs unpleasant to run.

But nowadays… I mean Java can be a bit verbose, but other than that it seems like a fine language and the JVM is pretty great. Plus we don’t have annoying Java applets in our browsers anymore (perhaps one of the main sources of legitimate Java hatred, and something so bad that we’ve intentionally all forgotten about it).

Re: Z Garbage Collector: The Next Generation

#63

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

There are some politics involved here. ZGC is competing against Shenandoah for the role of next-gen GC; ZGC is from Oracle and Shenandoah from RedHat. Because they are pretty evenly matched I find it unlikely that one would be promoted as default over the other

Re: Z Garbage Collector: The Next Generation

#64
post #53

Earlier quoted context omitted.

I 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 sw…

JVM still has some limitations. https://stackoverflow.com/a/2682962/31667 Those actually influence either the design or the performance of the higher level language.

That post is 13 years old.

Re: Z Garbage Collector: The Next Generation

#65

Earlier quoted context omitted.

JVM still has some limitations. https://stackoverflow.com/a/2682962/31667 Those actually influence either the design or the performance of the higher level language.

That post is 13 years old.

The answer is 6 years old if we count the last modification time.

Re: Z Garbage Collector: The Next Generation

#66
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.

Is it still fashionable to bash Java? I remember the bashing of Java around 15 years or so ago, IMO justifiably because it could be slow to the point of making programs unpleasant to run. But nowadays… I mean Java can be a bit verbose, but other than that it seems like a fine language and the JVM is pretty great. Plus we don’t have annoying Java applets in our browsers anymore (perhaps one of the main sources of legi…

Now I'm going to go look and see where Jython's parity is to Python.

EDIT: Only supports 2.7(x); that makes me sad.

Re: Z Garbage Collector: The Next Generation

#67

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

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

Yes, 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, 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.

Re: Z Garbage Collector: The Next Generation

#68

Earlier quoted context omitted.

I'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?

There 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 confi…

Are there any production-ready GCs that have strictly bounded latency? I'm not aware of any, and that means that GC is still too immature for use in about 95% of the computers in my house, the deeply embedded ones.

Re: Z Garbage Collector: The Next Generation

#69
post #58

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

How would machine learning help balance those trade-offs?

Re: Z Garbage Collector: The Next Generation

#70
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?

The 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.
Post reply on HN