Shenandoah performance problem

[Aleksey Shipilev]

On 10/21/19 10:29 PM, Attila Axt wrote:
> - I've applied the patch on the top of the stable jdk repository and its running with production
> load around since a day, without any major problems!

Excellent. The patches are already in jdk/jdk, so you might just use the vanilla repo, or binary
builds for jdk/jdk: https://builds.shipilev.net/openjdk-jdk/

> I did some measurements too. The following graphs show the average cpu time burned per second by
> different threads of the application:
>  - the 'Multi threaded workload' is 12 http threads serving API requests (on a 12 core machine)
>  - the 'Single threaded workload' is a single thread processing a queue
>  - the last graph is the cpu time burned by the GC Threads
> 
> https://imgur.com/S2vEmnL

I believe this shows that non-generational Shenandoah uses more CPU than a generational CMS: so the
GC cycles are longer on average, and then the total CPU time is larger. For single-threaded
workload, the heap occupancy might be much lower, so GC cycle length is smaller?

It would be interesting to zoom in and see if CPU utilization differs when GC is idle to confirm.
 --
Thanks,
-Aleksey