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.
Re:.NET GC Internals mini-series
by throwaway189262 on Saturday January 23, 2021 @08:49AM
(#25882181)
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
.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.