Troubles with Shenandoah

[Aleksey Shipilev]

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