Hacker News Re-Imagined

GC progress from JDK 8 to JDK 17

  • 318 points
  • 5 days ago

  • @carimura
  • Created a post
  • • 190 comments

GC progress from JDK 8 to JDK 17


@seanwilson 5 days

Replying to @carimura 🎙

How much do you need to worry about the GC causing frame stuttering when writing games now? Object pools are still important?

Reply


@gregaccount 5 days

Replying to @carimura 🎙

Looking at that, why isn't ZGC the standard GC in Java 17?

Reply


@thomascgalvin 5 days

Replying to @carimura 🎙

Those latency and pause-time numbers are pretty sexy. 200ms is still probably too high for some applications, but for everything I work on, this is incredible.

Reply


@pjmlp 5 days

Replying to @carimura 🎙

Note, only relevant for OpenJDK and the JVMs based on it, there are other GC available to other JVMs, including real time ones.

Reply


@bob1029 5 days

Replying to @carimura 🎙

As a .NET developer I am a little envious of all the GC knobs that Java developers get to play with.

If I could have only 1 new GC thing from Microsoft, it would be the ability to totally disable GC during the lifetime of a process. I don't even want to be able to turn it back on.

I have a lot of scenarios where I could get away with the cruise missile approach to garbage collection. No reason to keep things tidy if the whole world is gonna get vaporized after whatever activity completes. Why waste cycles cleaning things up when you could be providing less jitter to your users or otherwise processing more things per unit time?

Reply


@zokier 5 days

Replying to @carimura 🎙

Shenandoah GC is conspicuously missing despite having similar availability to ZGC and competitive performance characteristics.

Reply


@twic 5 days

Replying to @carimura 🎙

Shame this doesn't show the CMS collector, which was present in 8 and 11, but removed before 17. CMS was the go-to option for low-latency collection for a long time, so it would be good to see how it compares to the modern options.

It would be particularly interesting from the perspective of someone working in a shop which still has lots of latency-sensitive-ish workloads running on JDK 8 with CMS!

Reply


@ozim 5 days

Replying to @carimura 🎙

Which does not matter because most of stuff still rides Java 8.

Reply


@slater 5 days

Replying to @carimura 🎙

Might wanna save some bandwidth with that 1.25meg yet small-in-visual-size portfolio.png, yikes! XD

Reply


@Thaxll 5 days

Replying to @carimura 🎙

What is not shown is those benchmark is how much CPU is used for each GC. For example the latency for ZGC is much lower but does it means it uses more CPU than G1.

Reply


@kaba0 5 days

Replying to @carimura 🎙

Just sharing this really great benchmark series on JVM GCs, though it doesn’t include the latest versions of OpenJDK:

https://jet-start.sh/blog/2020/06/23/jdk-gc-benchmarks-remat...

Reply


@jimsimmons 5 days

Replying to @carimura 🎙

These GCs have a 1GB overhead when working with a 16GB heap. That’s 6% of your available memory. I was expecting modern GCs to be way more efficient so I’m kinda shocked this is what state of the art is.

I also wonder how much of the progress to “Sub (200) millisecond” latency target is due us just having faster machines. I honestly have no model to tie this to actual performance of my code. I guess it translates but not really sure how.

Not bagging on Java —— I am just surprised how inefficient an industrial strength GC can be. I understand why manual memory management still holds its own now.

Reply


@dandotway 5 days

Replying to @carimura 🎙

As Java is generally the fastest GC'd language, what's the current state of Java gamedev?

Once upon a time, this indie Java game called Minecraft became the most successful game of all time.

But from the few minutes of research I just did, Java cannot be deployed to many commercially important systems

  - Nintendo Switch
  - PlayStation
  - iOS
It appears Java is only still viable for Windows and Android, and the 1% Linux desktop market.

There used to be the GCJ project which would in theory let you run Java anywhere you had a C/C++ compiler, but Oracle's litigiousness killed that because the Java[TM] "platform" must run the official Java[TM] bytecode.

It appears C# via Monogame lets you deploy to all desktops (Win/Mac/Linux), mobiles (iOS/Android), and consoles (PS/Switch/Xbox). So ironically C# seems to now be the "write once, run anywhere" fulfillment of the original Java promise.

[EDIT: grammar.]

Reply


@mcdonje 5 days

Replying to @carimura 🎙

The throughput & latency charts have JDK8 pegged at 100%. Since that's meaningless and the value is in the difference between the JDK versions, it should be represented as a delta.

Reply


@vletal 5 days

Replying to @carimura 🎙

I like how this reached the top page soon after "Go does not need a Java-style GC" (https://news.ycombinator.com/item?id=29319160).

Moreover, are the significantly lower GC pause times help improve snappiness of GUI apps, such as IntelliJ IDEA?

Reply


About Us

site design / logo © 2021 Box Piper