Troubles with Shenandoah

[Simone Bordet]

Hi,

On Mon, Apr 8, 2019 at 12:59 PM Roman Kennke <rkennke at redhat.com> wrote:
>
> I also see it with latest jdk/jdk build.
>
> Also, I notice that latencies go through the roof. Usally in the us
> range, we suddenly get up to multi-seconds (!!) range.
>
>      @                _  1.394.016 µs (207208, 2,09%)
>                  @    _  2.788.033 µs (710359, 7,16%)
>                    @  _  4.182.050 µs (853475, 8,60%)
>                  @    _  5.576.067 µs (735210, 7,41%)
>                  @    _  6.970.084 µs (732427, 7,38%)
>                 @     _  8.364.101 µs (694916, 7,00%)
>               @       _  9.758.118 µs (593103, 5,98%)
>                  @    _  11.152.134 µs (715708, 7,21%) ^50%
>                   @   _  12.546.151 µs (769548, 7,76%)
>                  @    _  13.940.168 µs (739466, 7,45%)
>                    @  _  15.334.185 µs (854111, 8,61%)
>                  @    _  16.728.202 µs (739780, 7,46%)
>               @       _  18.122.219 µs (584904, 5,90%) ^85%
>
>
> WTF is going on here?!

Could be that your current settings are too small for the load you're
imposing, so either the client or the server cannot keep up.
You may need to typically increase the number of threads or the number
of selectors.

Other explanations could be full gcs, swapping, huge pages recycling, etc.

I did not need much load to trigger the Shenandoah failure, so perhaps
stay low on the load (batch size = 10 or decrement it down to 1 even),
and make the runs longer (batch count = 1_000 -> 100_000).

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz