Shenandoah performance problem

[Attila Axt]

I've promised some feedback!

- Unfortunatelly I can't run fastdebug build in production, because its 
much slower than the release build, and its violating our SLA 
requirements. Tried to reproduce the errors I posted previously in a 
synthetic environment but didn't manage to trigger those bugs.

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

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've plotted the average values, which we can use as a rough estimate of 
Shenandoah's overhead:

- On the single threaded workload the overhead is around +22.5%
- On the multi threaded workload the overhead is around +80%

I think that the extra overhead for the multi threaded workload is 
originating still from some lock-contention issues.

I will try to find the source for this extra overhead, and if I succeed, 
I will send you a reproducer testcase or at least some profiling results.


Thanks again for the fix,
   axt

On 10/18/19 1:51 PM, Roman Kennke wrote:
> You could try to run with fastdebug build, which builds in lots of
> asserts. In addition to that, try running with -XX:+ShenandoahVerify.
> Maybe this gives us some clues.
>

On 10/18/19 4:04 PM, Aleksey Shipilev wrote:
> For this work, prefer https://hg.openjdk.java.net/jdk/jdk/ (the mainline dev) repository as the
> base. Also note I just published the RFR for JDK-8232575 here, which has minor touchups that lets it
> pass most (all?) tests:
>    https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010794.html  --
> Thanks,
> -Aleksey