Java's new collectors ZGC and Shenandoah are state of the art, perhaps the best GC's in the world. There's collectors with lower latency and higher throughput but nothing out there that achieves both like Java's new collectors do.
It's a large part of why you hear that Java "performs better in production" than Go and C# even though those languages are faster in micro benchmarks. Java doesn't have value types and generates a ton of garbage but the collectors are good enough that it's still competitive with these faster languages.
Some will tell you that Go's GC is state of the art but I disagree. Last time it came up I started a huge flamewar in the comments so I'll avoid comparing them :).
.NET has made a ton of performance progress in the last 4 years, and a lot of people's ideas about the performance differences are based on .NET from the pre .NET Core days.
I haven't found a comparison of JVM vs CLR GC but I know the .NET team has intended to introduce a ZGC style collector for a while.
The need is not as severe in CLR because it produces less garbage.
But CLR stop the world pauses are long and it's definitely a problem for some uses cases. Many companies focus on their P99 latency these days and a 1 second GC pause will ruin those metrics. And stuff like HFT just can't be done in C# without turning GC off
______
¹ Plus a number of algorithmic improvements and the ability to leverage specific CPU instructions that help as well.
Yes good point, this is likely a big difference. Maybe Java records will help a lot.
Even if it has the same name to other vendor, it doesn't mean it is 1:1, as each vendor fine tunes their own implementation.
This also applies to .NET actually, as there are other implementations besides .NET Framework/Core.
So it always boils down to profiling.
Isn't the Shenandoah GC supposed to be able to gc asynchronously without pauses?