Troubles with Shenandoah

[Simone Bordet]

Hi,

On Mon, Apr 8, 2019 at 9:28 PM Aleksey Shipilev <shade at redhat.com> wrote:
> Yes. Here's a taste when nothing else is happening, and only memory commit is done:
>
> $ time java -Xms100g -Xmx100g -XX:+AlwaysPreTouch -XX:+UseSerialGC -version
> openjdk version "13-internal" 2019-09-17
> OpenJDK Runtime Environment (build 13-internal+0-adhoc.shade.jdk-jdk)
> OpenJDK 64-Bit Server VM (build 13-internal+0-adhoc.shade.jdk-jdk, mixed mode)
>
> real    0m33.461s
> user    0m4.733s
> sys     0m28.600s
>
> ...when other things happen concurrently, the whole thing might take a while to satisfy even a small
> one-off request.

Holy cow!

> Yes. Just don't be surprised when concurrent collectors do not give the latency boost there :)

I'm not expecting a median latency boost here.
I actually had no expectations and was just curious as to what could
have happened when running the CometD benchmark with ZGC and
Shenandoah.

But we have people interested in reducing max latency as much as
possible, even sacrificing some throughput and median latency, so ZGC
and Shenandoah are worth exploring.
We (as the Jetty team) take the hit of trying these new GCs early so
at least we have some knowledge when people ask us about them :)

Thanks!


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