Why does Quarkus use ParallelGC as the default garbage collector in its Docker image?

[mielecmichal]

The Quarkus Docker extension uses Red Hat’s ubi9/openjdk-21-runtime image, which defaults to ParallelGC. I couldn't find any explanation for this choice or any GC recommendations in the official Quarkus documentation.

I have a few questions:

1. Is the use of ParallelGC a deliberate decision by Quarkus, or simply inherited from the base image?
2. As far as I know, ParallelGC generally offers higher throughput but with longer pause times compared to G1GC, which is the JDK’s default. Shouldn't Quarkus favor lower-pause options, considering most users likely aren’t operating at massive scale?
3. I noticed different memory usage patterns with the scheduler extension, which allocates objects every second (trigger thread). With ParallelGC, heap usage climbs to ~80% before collecting (a classic sawtooth pattern), while G1GC keeps memory usage relatively flat. (My app is running in Kubernetes, where heap min and max are set near the cgroup limit to avoid resizing). In short, wouldn't the G1GC be a more universally suitable default?

[mschorsch]

We changed the default garbage collector to G1GC in ubi9/openjdk-21-runtime for all our Quarkus apps.

[mielecmichal]

Could you share why you decided to change it ,instead of sticking to Quarkus JDK image default? What was the reasoning or use case in your project?

[cescoffier]

Finding the best GC without knowing the application and limits is hard. But it's configurable, see:
https://github.com/rh-openjdk/redhat-openjdk-containers/blob/ubi9/modules/jvm/artifacts/jvm/java-default-options#L45-L82

[mielecmichal]

Considering it's a hard choice, do we know why ParallelGC was chosen over G1GC in the Quarkus Docker extension?
I'm curious whether this was an intentional performance decision made with Quarkus in mind, or simply inherited from the base image.

[cescoffier]

It is inherited from the base image - but it was an intentional choice in the base image. You can ask on their repo directly.

[jmtd]

Hi -- it was based on some benchmarking and metrics, but those were a long time ago and I can't remember much of the specifics. We could look at re-running the benchmarks to see whether it's a sensible default Today or not. If someone feels strongly we should change it, it would be helpful to file a tracker issue to capture discussion, ideally here but here would do too in a pinch.

[mschorsch]

Maybe G1Gc woud be a better choice in the future because of

To benefit from the natively compiled code in AOT archives, the garbage collector used at runtime needs to match the same garbage collector used when you recorded the AOT archives.

To avoid this mismatch it’s best to pick a garbage collector explicitly; and since several AOT related optimisations today only apply to G1, let’s enforce the use of G1GC.

https://quarkus.io/blog/quarkus-and-leyden/#force-the-use-of-g1gc

[jmtd]

Could be, yes. I'll make sure we re-run the benchmarking as part of work following #49099 , and I'll be sure that this alignment use-case is in the mix there (I'm fairly sure the benchmarks were run before Quarkus existed, so definitely didn't consider alignment with AOT)