[EXTERNAL] Re: RFC: G1 as default collector (for real this time)

[Stefan Johansson]

Thanks for sharing these results Monica,

As Thomas mentioned we have done some testing comparing Serial to G1 in 
small environments as well. Our conclusions are similar to yours, G1 
nowdays handles the small environments pretty good.

I used SPECjbb2005, and my focus was to compare throughput given a fixed 
memory usage. The reason for this is that the low native memory overhead 
of Serial (no marking bitmap etc) is often used as an argument to use it 
in small environments. On the other hand, the region based heap layout 
of G1 can in many cases offer a better out of the box heap utilization 
compared to Serial. To test this and to make a fair comparison I 
configure Serial to have a slightly larger heap to get an overall equal 
memory consumption (using the peak PSS usage in Linux as the measure).

SpecJBB2005 by default runs 1 to 8 warehouses, where warehouses 
corresponds to worker threads. I did run this in a cgroup environment 
with 1CPU and 1G memory. By default this will give G1 a 256m max heap, 
which I fixed using Xmx and Xms. To let Serial use as much memory in 
total as G1 I configured it with a 288MB heap. With this setup Serial 
and G1 get a very similar score with a recent JDK 25 build. The 
calculated score only takes warehouse 1 and 2 into account and looking 
at the result/score for 8 warehouses G1 is ~10% better. So it looks like 
G1 is able to handle high pressure better compared to Serial.

These results are without the new improved barriers for G1, when using a 
build with the new barrier the G1 results are improved by roughly 3%. 
This is a use-case not at all caring about latency and the fact the G1 
is still performing this good, also points towards it being a suitable 
default even for small environments.

I've also played around a bit with restricting the amount of concurrent 
work done with G1, to see how a G1 STW-only mode would perform, and on a 
single CPU system this looks beneficial when we start to run with more 
worker threads. But I don't suspect it's that common to run small cloud 
services at 100% load, so having a default that can do concurrent work 
seems reasonable.

Thanks,
Stefan


On 2025-03-18 00:59, Monica Beckwith wrote:
> Hi Thomas, Erik, and all,
>
> This is an important and timely discussion, and I appreciate the 
> insights on how the gap between SerialGC and G1GC has diminished over 
> time. Based on recent comparative tests of out-of-the-box GC 
> configurations (-Xmx only), I wanted to share some data-backed 
> observations that might help validate this shift.
>
> I tested G1GC and SerialGC under 1-core/2GB and 2-core/2GB 
> containerized environments (512MB < -Xmx <1.5GB), running SPECJBB2015 
> with and without stress tests. The key findings:
>
> *Throughput (max_jOPS & critical_jOPS):*
>
>  *
>     G1GC consistently outperforms SerialGC.
>  *
>     1 core: G1GC shows a 1.78× increase in max_jOPS.
>  *
>     2 cores: G1GC shows a 2.84× improvement over SerialGC.
>
>
> *Latency and Stop-the-World (STW) Impact:*
>
>  *
>     SerialGC struggles under stress, with frequent full GCs leading to
>     long pauses.
>  *
>     G1GC’s incremental collections keep pause times lower, especially
>     under stress load.
>  *
>     critical_jOPS, a key SLA metric, is 4.5× higher for G1GC on 2 cores.
>
>
> *Memory Behavior & Stability:*
>
>  *
>     In 512MB heap configurations, SerialGC encountered OOM failures
>     due to heap exhaustion.
>
>
> Given these results, it seems reasonable to reconsider why SerialGC 
> remains the default in small environments when G1GC offers clear 
> performance and stability advantages.
>
> Looking forward to thoughts on this.
>
> Best,
> Monica
>
> P.S.: I haven’t tested for <512MB heaps yet, as that requires a 
> different test config I’m still working on. I’d also love to hear from 
> anyone running single-threaded, CPU-bound workloads if they have 
> observations to share.
>
>
> ------------------------------------------------------------------------
> *From:* hotspot-gc-dev <hotspot-gc-dev-retn at openjdk.org> on behalf of 
> Thomas Schatzl <thomas.schatzl at oracle.com>
> *Sent:* Monday, February 24, 2025 2:33 AM
> *To:* Erik Osterlund <erik.osterlund at oracle.com>
> *Cc:* hotspot-gc-dev at openjdk.org <hotspot-gc-dev at openjdk.org>
> *Subject:* [EXTERNAL] Re: RFC: G1 as default collector (for real this 
> time)
> Hi,
>
> On 21.02.25 15:02, Erik Osterlund wrote:
> > Hi Thomas,
> >
> [...]> 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.
>
> +1
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250401/d34253ea/attachment.htm>