Java 9 GC

Performance Tuning
#21

Sorry! ;D To try and say it in a simpler way, if you’re doing any (soft) real-time task your code has a deadline to meet. If you’re doing a 60 frames per second game, to not miss a frame your code has to complete what it’s doing each frame in lower than (1/60 sec) ~16ms. If the GC kicks in then the time it takes and the time your code takes must be lower than ~16ms. In fact, in a multi-process system you almost certainly can’t take the full 16ms.

Audio with something like JACK processes in a callback into Java at maybe more like 300 or 600 frames per second. And missed deadlines are a lot more noticeable in audio. Therefore you’re looking at a situation where your code (and possibly GC) has to guarantee to run in less than a few ms. If Shenandoah is working well for the higher framerates of audio, then it should also work well for a 60fps game.

#22

I’d say the problem is that there is hardly anyone at Oracle or the JCP that cares about games written in Java, which:

  1. have not 128GB of server machine memory footprint but rather 1-2GB
  2. value consistent low-latency GC more than high throughput

Java EE (sorry, I meant Jakarta EE) application servers certainly don’t care whether GC takes 10ms or 50ms at times. There are certainly use-cases for 2. with even lower memory footprints in the tens or hundreds of megabytes for embedded systems, but that’s where dedicated commercial real-time JVMs from for example Aonix/Perc/PTC come into play. This is probably not something where Oracle or the OpenJDK wants to excel in.

#23

Not sure about Oracle, although the web is changing! Maybe them donating (ditching) EE says something?

But I’m sure some OpenJDK partners have an interest in 2. Which makes me think. OpenJ9 with Metronome GC might be worth some experiments.