Live data from Hacker News

Why is Arrays.fill 265 times slower on G1GC?

krzysztofslusarski.github.io

31–33 of 33 posts

Re: Why is Arrays.fill 265 times slower on G1GC?

#31
post #25

Earlier quoted context omitted.

If anything, I think it's not unlikely that ZGC will become the default at some point, as it matures. It's hard to beat Parallel on batch workloads, although G1 is getting there. ZGC is unparalleled for low-latency (GC pauses are just gone). G1 is intended to offer a compromise that could be a reasonable default.

I would be very surprised if ZGC became the default, because it incurs a significant overhead penalty to eliminate those GC pauses. All else equal you're effectively just sacrificing throughput for latency, since it's doing a bunch of extra housekeeping in the background (foreshadowing...) That's a perfectly reasonable tradeoff to make if low latency is a priority (or perhaps more importantly if having very consisent…

> I would be very surprised if ZGC became the default, because it incurs a significant overhead penalty to eliminate those GC pauses

That throughput penalty is not very high with generational ZGC. It's not zero, but it's not very high, either. What ZGC mostly does is spread the memory management activity more evenly across the duration of the program (this does have a cost due to barriers being active more, but it's not huge). But we have some work planned to improve ZGC even further, which is why I didn't say I think it will become the default imminently, only eventually.

> ZGC performance is _catastrophically_ bad with That may well be true, but the JVM can automatically choose a different default algorithm for these circumstances. Indeed, until very recently, the default for low-CPU environments was different (Serial) than for bigger ones (G1).

Re: Why is Arrays.fill 265 times slower on G1GC?

#32
post #25

Earlier quoted context omitted.

If anything, I think it's not unlikely that ZGC will become the default at some point, as it matures. It's hard to beat Parallel on batch workloads, although G1 is getting there. ZGC is unparalleled for low-latency (GC pauses are just gone). G1 is intended to offer a compromise that could be a reasonable default.

I have no qualms with ZGC being the default. The low latency that it offers at near G1 speeds is a very good trade off (IMO). I just have a problem with G1 because in my experience, the best place for it is fairly large heaps. Get something sub 2 or even 10G, especially if you have a few cores to offer, and the parallel and often even the serial collector will give G1 latency even on major collections with superior t…

Are you talking about G1 in JDK 25, JDK 26, or JDK 27? While G1 isn't changing quite as fast as ZGC, it changes quite a bit from release to release. I believe that G1 has been made the default even for small machines in JDK 27 because of some very recent changes that have made G1 more suitable in smaller environments.

Re: Why is Arrays.fill 265 times slower on G1GC?

#33
post #25

Earlier quoted context omitted.

If anything, I think it's not unlikely that ZGC will become the default at some point, as it matures. It's hard to beat Parallel on batch workloads, although G1 is getting there. ZGC is unparalleled for low-latency (GC pauses are just gone). G1 is intended to offer a compromise that could be a reasonable default.

I would be very surprised if ZGC became the default, because it incurs a significant overhead penalty to eliminate those GC pauses. All else equal you're effectively just sacrificing throughput for latency, since it's doing a bunch of extra housekeeping in the background (foreshadowing...) That's a perfectly reasonable tradeoff to make if low latency is a priority (or perhaps more importantly if having very consisent…

[dead]
Post reply on HN