Troubles with Shenandoah

[Simone Bordet]

Hi,

On Tue, Apr 9, 2019 at 11:13 PM Aleksey Shipilev <shade at redhat.com> wrote:
> My bet is on long commits after full uncommit triggered by System.gc() wrecked up everything. Maybe
> it is not a GC bug, but rather application layer loses the messages with timeouts?

Definitely, after seeing how long it takes. The application timeout is
5 seconds so it could have tripped.

FYI, in my Shenandoah run (1 server, 48g heap, 4 client machines at
each 1k clients at 10k messages/s) the max pause was about 4ms.
The ZGC run had a max pause of about 2 ms.
The G1 run had a max pause of about 33 ms (all young collections).

I'll try now with smaller and smaller heaps.

I have to say that after the initial struggle with Shenandoah, I'm
impressed by both Shenandoah and ZGC.
As a user, I get the feeling that one can kind of "forget" the GC as
pauses will be super low.
Also, tuning seems to be reduced to "increase heap size if you have
problems" - no more generation sizing, survivor age tuning, etc. and
with that no need to know what a generation is, what a survivor is,
etc.

Congrats so far and thanks for the help!

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