Troubles with Shenandoah

[Simone Bordet]

Hi,

On Mon, Apr 8, 2019 at 9:11 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 4/8/19 9:01 PM, Roman Kennke wrote:
> > This seems particularily bad, considering that this benchmark doesn't
> > seem to do very much allocations to begin with. I can run it with 16GB
> > without significant GC activity, I suspect it can easily run in 8GB or
> > 4GB and actual GC still wouldn't matter much. Running it in several
> > dozens of GB seems not useful.
>
> +1.
>
> I managed to run the workload in 1G heap with Shenandoah, with only some minor loss in latency.
> Larger heaps would be beneficial for concurrent collectors anyway, as they would do fewer cycles. But
> that would probably not matter past some decently sized heap, because the cycles themselves are
> short, given the workload is mostly-young.

I agree with your observations: with default configuration and 1
client machine (or same machine) the load is not much.

I am actually running this benchmark with 4 client machines against 1 server.
With my configuration, I saw 10-20 ms pauses in ZGC due to allocation
stalls with 2 GiB heap on the server.
I expect Shenandoah to have similar behavior, but have not been able
to perform a full run with Shenandoah yet.

All of that playing with GCs, and heap sizes, etc. to understand
better these new GCs.
FYI I will present them (an introductive talk - in Italian) to Voxxed
Milan (https://vxdmilan2019.confinabox.com/talk/WES-2204/Concurrent_Garbage_Collectors:_ZGC_&_Shenandoah).
The idea is to get people to know they exist, so they start playing with them.

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