Shenandoah & realtime

[Roman Kennke]

Hi Stefan,

> So we are running a music-playing bot in Java which streams Shoutcast to
> Discord. Discord requests audio in 20 ms intervals. I just switched the VM
> to Shenandoah, using the compact profile.
> 
> My question is, if there is any sort of general guarantee or
> pseudo-guarantee as to GC pauses with Shenandoah. You know, like that 10 ms
> figure that the ZGC guys are throwing around.

Any such statement is bound to be partial-bogus, especially in the Java
world. When we started work on Shenandoah, our goal was to get <10ms
pauses for most relevant scenarios, and we do meet this goal. For
example, most workloads do <1ms pauses on my machine. However, there are
always scenarios where this goes out of the window. A few examples:

- It heavily depends on your workload. For example, if you make heavy
use of large linked lists, you have a chance to wind up with a linked
list that is unmarked at the final-mark pause and need to be marked
through, by a single thread. There are other somewhat pathological
scenarios that can cause pauses to grow e.g. abuse of some JNI stuff or
weak reference stuff, etc.
- Slow hardware. <1ms pauses on my box easily means several ms pauses on
raspberry-pi grade hardware. If your music-player is intended to run on
such hardware, then you may need to reconsider your latency goal :-)
- Even if GC pauses are good, you may be affected by other pauses (e.g.
deoptimization, biased locking), or even just local latencies that are
not accounted-for anywhere.

That being said, it's probably a good idea to run your application on
your intended hardware for a while with -Xlog:gc+stats and see what the
statistics on JVM shutdown say about pause times. Or even run with
-Xlog:gc altogether and look at the GC pauses one-by-one.

> Because 10 ms would obviously be perfect for this application.

As said above. I think you *should* be good with Shenandoah, with a
bunch of caveats (that are general in nature and would affect any GC).


> Also, is the compact profile detrimental for realtime applications?

It may be too aggressive. Watch GC logs and maybe tune down the
thresholds if you see it's doing too much work for nothing, or keeps
trimming down the heap just to re-grow it a second later.

> I'm
> just so in love with the compact profile, but maybe I shouldn't have chosen
> it for an application like this.

:-)

Hope that helps!

Cheers,
Roman