Troubles with Shenandoah

[Aleksey Shipilev]

On 4/8/19 9:21 PM, Simone Bordet wrote:
> On Mon, Apr 8, 2019 at 8:31 PM Aleksey Shipilev <shade at redhat.com> wrote:
>> On 4/7/19 2:41 PM, Simone Bordet wrote:
>> The benchmark calls System.gc() between benchmark rounds, which uncommits almost entire Shenandoah
>> heap, which is intentional, because Shenandoah treats System.gc() as the command to compact the heap
>> as densely as possible. But this also means the next benchmarking round has to commit all that
>> memory back. This gives you the latency hit, which probably manifests as timeouts/lost packets too?
> 
> Timeouts and lost packets would only happen if the latency/pause is
> quite long, 5+ seconds.
> Could recommitting the memory cause pauses this long?

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.

>> I also note the workload is fully-young, so differences between current GCs would probably be small.
> 
> Indeed. The client connections and session objects are long lived, so
> the case is a lot of objects that die young, referenced by objects
> that are long lived.

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


-- 
Thanks,
-Aleksey