.NET GC is nothing to write home about, pretty standard with long stop the world phase. It's not super interesting so nobody raves about it.

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 :).

Citation needed. Overall .NET performance usually beats Java in benchmarks today , so if the GC is substantively less good, that shouldn't be possible. I've not seen GC comparisons specifically though so if you know of some recent ones let me know.

.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.

Many recent improvements in .NET performance are enabled by reducing or removing allocations in hot paths, so the GC has to do less work¹. The point was mostly that the .NET GC can get away with not being as advanced since it commonly has to do less work than in Java anyway. C# gives the developer more low-level control over what actually runs on the CPU in the end, so there's a slight shift in responsibility for performance from the JIT/GC towards the developer (although the latter two also improve, of course).

______

¹ Plus a number of algorithmic improvements and the ability to leverage specific CPU instructions that help as well.

Micro benchmarks are written to avoid creating garbage since code is faster that way. C# wins these comparisons easily.

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

> Java doesn't have value types and generates a ton of garbage

Yes good point, this is likely a big difference. Maybe Java records will help a lot.

I am quite interested in this also and I confirm it from empirical standpoint - I never had a single episode of .NET GC but it was usual stuff on Java apps. We even had 3 month session in GC optimization directly with the guy working at Sun on it.

Although there are many valid comments here, I will just leave here a voice from the .NET GC architect herself - https://devblogs.microsoft.com/dotnet/how-to-evaluate-info-y....

Regarding Java GC's it depends pretty much which JVM implementation, and what GC is chosen from the pleothara that each vendor packages.

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.

I don't use Java but I was under the impression that it has the most sophisticated gc's available.

Isn't the Shenandoah GC supposed to be able to gc asynchronously without pauses?

ZGC is the state of the art