Troubles with Shenandoah

[Roman Kennke]

This seems particularily bad, considering that this benchmark doesn't
seem to do very much allocations to begin with. I can run it with 16GB
without significant GC activity, I suspect it can easily run in 8GB or
4GB and actual GC still wouldn't matter much. Running it in several
dozens of GB seems not useful.

Roman

> On 4/7/19 2:41 PM, Simone Bordet wrote:
> > I will happily re-run the benchmark with your suggestions.
> 
> After running the benchmark myself, at least one trouble I see is
> here:
> 
> > -XX:InitialHeapSize=17179869184 -XX:MaxHeapSize=51539607552
> > -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240
> > -XX:+SegmentedCodeCache -XX:+UnlockExperimentalVMOptions
> > -XX:+UseShenandoahGC
> 
> The benchmark calls System.gc() between benchmark rounds, which
> uncommits almost entire Shenandoah
> heap, which is intentional, because Shenandoah treats System.gc() as
> the command to compact the heap
> as densely as possible. But this also means the next benchmarking
> round has to commit all that
> memory back. This gives you the latency hit, which probably manifests
> as timeouts/lost packets too?
> The timing distribution had improved very significantly after either
> -XX:-ShenandoahUncommit or
> -XX:+AlwaysPreTouch is supplied.
> 
> For comparison across GCs and OSes that have different takes on heap
> management, I would run with
> "-Xms${H}g -Xmx${H}g -XX:+AlwaysPreTouch" to stick the heap at max
> capacity and wired up at all
> times. This advice applies to Shenandoah [1], as well as other
> OpenJDK collectors.
> 
> I also note the workload is fully-young, so differences between
> current GCs would probably be small.
> 
> -Aleksey
> 
> [1] See "Other recommended JVM options":
> https://wiki.openjdk.java.net/display/shenandoah/Main#Main-PerformanceGuidelinesandDiagnostics
>