Shenandoah & realtime

[Stefan Reich]

Hi Roman, thanks a lot. The hardware is a v-server which has a performance
comparable to a standard desktop CPU. All in all, I think I'll be good.
Allocation rates should be tolerable, the application uses less than core
in total. I reniced the whole Java process to -10. I'll keep monitoring. :)

On Sun, Oct 20, 2019, 18:13 Roman Kennke <rkennke at redhat.com> wrote:

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