Live data from Hacker News

Z Garbage Collector: The Next Generation

inside.java

71–80 of 126 posts

Re: Z Garbage Collector: The Next Generation

#71
post #53
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 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…

I haven't been in that world since Java 7. What's the startup time on the JVM these days? It used to be a pretty hefty cost, and it didn't seem like it would get much better because of the way class loading was done.

Re: Z Garbage Collector: The Next Generation

#72
post #61

Earlier quoted context omitted.

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

But this is vacuous and unrelated to the halting problem or Rice's Thm. A program that emits "Yes" on every input will decide some property of programs with zero false negatives.

Re: Z Garbage Collector: The Next Generation

#73

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?

I recently did a deep dive on gc issues at work, and compared eden the default collector and z.

Our app was collecting pretty heavily, and an average collection time of about 50ms. With Z, and Linux huge pages it was collecting sub millisecond. This was at the cost of a bit more cpu, as z uses more threads for collection.

Using gatling for performance testing, we saw a small increase in requests per second. But the benefit was a smoother response time, with less spikes to high p9X measures.

Using flight recorder with this is a great way to get details of how the gc is performing.

Addendum: As noted below zgc uses more memory, I only found it viable on 16GB heaps or above. With it really improving performance around 32GB.

Re: Z Garbage Collector: The Next Generation

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

The excellent backwards compatibility rocks too. This weekend I wanted a library to diagram the class hierarchy of a Java project I put together.

I found a 10 year old library that worked with no issues, I was done in minutes even though I rarely use Java or Clojure so my familiarity is low. There are very few languages where I would have a similar experience.

https://github.com/stuartsierra/class-diagram

Re: Z Garbage Collector: The Next Generation

#75
post #66

Earlier quoted context omitted.

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.

Graal Python is compatible with python 3.x https://www.graalvm.org/python/

Re: Z Garbage Collector: The Next Generation

#76
post #68

Earlier quoted context omitted.

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.

Metronome did this for embedded hard realtime use cases. I don't know much about it. ZGC has bounded pause latency at least but it's not really meant for very small machines. Android has used a pauseless GC for a while.

Re: Z Garbage Collector: The Next Generation

#77
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…

> Is it still fashionable to bash Java?

People do it more now rather than less.

Nowadays people run on hype and need a scapegoat.

Re: Z Garbage Collector: The Next Generation

#78

Earlier quoted context omitted.

That post is 13 years old.

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

And the last modification was only wording, with the same 13 years old content. [0] Always check what changed in SO posts, because this practice is very common.

[0] https://stackoverflow.com/posts/2682962/revisions

Re: Z Garbage Collector: The Next Generation

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

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

Re: Z Garbage Collector: The Next Generation

#80
post #74
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.

The excellent backwards compatibility rocks too. This weekend I wanted a library to diagram the class hierarchy of a Java project I put together. I found a 10 year old library that worked with no issues, I was done in minutes even though I rarely use Java or Clojure so my familiarity is low. There are very few languages where I would have a similar experience. https://github.com/stuartsierra/class-diagram

I had a similar experience with some random jar visualizing some algorithm which I downloaded from a professor’s website, which just worked.
Post reply on HN