Investigate adoption of Shenandoah/ZGC garbage collector

[ryanemerson]

Description

744 uncovered a need for new GC settings in order to act as our baseline. Work so far has focused on migrating from Parallel GC to G1. However, once a G1 baseline has been determined we should investigate potential performance benefits gained by adopting the Shenandoah garabage collector policy.

Discussion

No response

Motivation

No response

Details

No response

[kami619]

Updating this ticket to also explore ZGC collector when we have the opportunity to run the tests.

[kami619]

https://developers.redhat.com/articles/2024/05/28/beginners-guide-shenandoah-garbage-collector

There was a new blog that was published in time for this task. Some excerpt on the usage of non-generational Shenandoah collector usage recommendations.

_

When to use Shenandoah GC You can use non-generational Shenandoah adequately in situations such as huge workloads with neither random nor too much generational overload.

Examples of situations can be applications with constant allocation (and even usage in general) of objects.

Other examples of situations can be applications where the objects are older and the overhead of creating new objects is small, percentage-wise proportionally to the size and number of regions to be cleaned.

In some instances container usage can be very adequate and even recommended, but it depends on the use case, naturally.

When not to use Shenandoah GC Shenandoah (in its non-generational form) is not applicable for all situations and workloads, and there will be workloads where its performance will be hurt more than helped by Shenandoah, given it is not generational. Being non-generational is a core part of the algorithm and helps considerably in several aspects, but it can hurt in other more specific aspects.

An example is when a high number of very short-lived objects is created at random periods, which leads to all the threads kicking in and running at the same time and can lead to several subsequent full pauses in a roll. For those cases, a generational collector, like G1GC and Parallel, would likely handle better the situation—by splitting the collection into phases. For those generational workloads, Amazon's Correto has developed its generational Shenandoah, GenShen.

Consequently, there needs to be due diligence from the development team to verify how a non-generational collector is handling—in terms of latency, throughput, and less (but not least) footprint—which is most of the time sacrificed in several situations when developing in Java or (self/auto) collected garbage collection development.

However, this non-generational aspect will likely change given the support of Generational Shenandoah to be introduced in later releases, likely OpenJDK 21+. In any case, the main recommendation is to benchmark the application with the Shenandoah and other collectors such as G1GC and ParallelGC for a more direct comparison. I would recommend doing that even before tuning Shenandoah.

_