RFC: G1 as default collector (for real this time)

[Erik Osterlund]

Hi Thomas,

When G1 came, the main focus was making it scale better to larger workloads. It did so with a more well rounded balance between latency, throughput and memory footprint than other collectors, and became a good fit for the default GC. Given its initial focus as a region based collector that could scale better, it made sense that Serial was still better in smaller environments where that scaling wasn’t really needed. When G1 was made default, it made sense to stay away from the small machine realm.

Since then, the gap between Serial and G1 has diminished over time, and it still keeps on diminishing. So it certainly makes sense to consider the option of changing Serial -> G1 by default in the small realm. The result of doing that is, as you point out, that there is a single default GC invariant of the environment scale, instead of having an exception for small environments. That’s nice.

There is however a flip side for that argument on the other side of the scaling spectrum, where ZGC is probably a better fit on the even larger scale. So while it’s true that the effect of a Serial -> G1 default change is a static default GC, I just think we should mind the fact that there is more uncertainty on the larger end of the scale. I’m not proposing any changes, just saying that maybe we should be careful about stressing the importance of having a static default GC, if we don’t know if that is the better strategy on the larger end of the scale or not, going forward.

/Erik

> On 19 Feb 2025, at 14:16, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
> 
>  there have been some recent discussions around making G1 the default for all use-cases, both internally at Oracle and at the OpenJDK Committers Workshop. With this e-mail I want to bring this subject to a wider audience to gather feedback around potential problems with such a move.
> 
> 
> As you all may know, G1 is the default collector in the Hotspot VM. However in some situations, some say in (too) many situations, the VM selects Serial GC "by default" anyway. :)
> 
> From what I understand there are the following reasons to keep Serial GC _as default option_ in the context of "small" environments:
> 
>  * throughput: G1's large write barrier makes an argument about throughput being too far off and noticeable. Ongoing efforts ([1] which we plan for JDK 25) show that the difference is going to be much smaller if it ever was.
> 
> Further, as soon as Serial GC is running for longer this advantage diminishes a lot due to full collections and can result in G1 actually performing better.
> 
>  * (native) memory footprint: G1 has made great strides in native memory usage.
> 
> In the past particularly remembered sets were of concern, but their memory usage has been reduced significantly over the past few years.
> E.g. with above change the entire young gen remembered set is also managed on the card table exactly like in Serial GC.
> 
> [I would also like to state that I would be surprised if remembered sets, with a recent JDK and G1, are ever an issue with heaps Serial GC targets]
> 
> Heap management tends to be worse with Serial GC, mostly due to its strict generational boundaries. G1's region based layout avoids wasting memory.
> 
>  * latency: if this has ever been a disadvantage, Serial GC's full collections are worse compared to G1's incremental collections.
> 
>  * startup: the time to start up the VM is not that different between these two collectors. Other components are much more relevant here.
> 
>  * historical inertia: at the time there was need to select a default, there has been nothing but Serial and Parallel GC. JDK 9 simply replaced Parallel GC as default for "server class" machines, probably as path of lesser resistance and at the time known shortcomings in some of the above areas.
> 
> Some initial testing showed that Serial GC much better when constraining it to the same environment (single thread, heaps < 1.7g) than G1.
> 
> At the same time, looking at the current situation from an end users point of view, it is very much confusing for them, getting a different garbage collector depending on environment, based on some somewhat arguable criteria?
> 
> This change would also make the expectations ("g1 is default since jdk 9") match the actual behavior.
> 
> I am looking forward to hear about your opinion about making G1 unconditionally default.
> 
> Thanks,
>  Thomas
> 
> [1] https://bugs.openjdk.org/browse/JDK-8340827