简体繁体 English

CLR GC 与 JVM 上最新的 ZGC 和 Shenandoah GC 相比如何？

[英]How does CLR GC compare to latest ZGC and Shenandoah GC on JVM?

原文 2020-10-07 21:30:16 1 2 c#/ .net/ garbage-collection/ jvm/ clr

In recent years a lot of features were added to C# (which is no 1 player in .NET world) to reduce GC pressure.近年来，C#（在 .NET 世界中排名第一）中添加了许多功能以减少 GC 压力。 It is indisputable that all these features enable us to build better and more efficient applications.无可争辩的是，所有这些特性都使我们能够构建更好、更高效的应用程序。 But regardless of language and VM (CLR, JVM) features being added over time a performant and non-blocking GC is the key performance factor for managed applications.但无论语言和 VM（CLR、JVM）特性如何随着时间的推移而添加，高性能和非阻塞 GC 是托管应用程序的关键性能因素。

Recently in JVM world two new GC's have emerged and it seems they deliver remarkable metrics.最近在 JVM 世界中出现了两个新的 GC，它们似乎提供了非凡的指标。 There are sources (including authors) that provide benchmarks and technical insights about those GCs.有一些来源（包括作者）提供了关于这些 GC 的基准和技术见解。 We can learn that maximum STW (stop the world) interval "is promised" to be no longer then 10 ms and typically oscillates below 1 ms on average regardless of the heap size.我们可以了解到，“承诺”的最大 STW（停止世界）间隔不再超过 10 毫秒，并且无论堆大小如何，通常平均都在 1 毫秒以下。 There are also tests which show the new GCs overhead is well balanced and does not negatively impact application throughput whereas at the same time drastically reduce (by factor 10 or more) STW pauses.还有一些测试表明，新的 GC 开销得到了很好的平衡，不会对应用程序吞吐量产生负面影响，同时大幅减少（减少 10 倍或更多）STW 暂停。

On the other hand there is very little information about CLR GCs.另一方面，关于 CLR GC 的信息很少。 Are there any up to date sources to see how CLR GCs (4.8, Core 3.1, .NET 5) compare to latest JVM achievements?是否有任何最新来源可以查看 CLR GC（4.8、Core 3.1、.NET 5）与最新 JVM 成就的比较？ I could find some older sources which discussed CLR GC vs G1.我可以找到一些讨论 CLR GC 与 G1 的较旧来源。 But today G1 is no match for ZGC/Shenandoah and old sources do not show the reality as it is today.但是今天 G1 不是 ZGC/Shenandoah 的对手，旧的消息来源并没有像今天这样显示现实。 Considering there are no newer sources we could conclude that CLR GC metrics did not improve significantly since then.考虑到没有更新的来源，我们可以得出结论，从那时起，CLR GC 指标并没有显着改善。 But it would look like a real problem for .NET platform in 2020 because average STW around 20-30 ms with occasional jumps to 300+ ms look really bad when compared to 1ms average and 10ms maximum (as the GCs makers claim and test seem to confirm) pauses on JVM.但这对于 2020 年的 .NET 平台来说似乎是一个真正的问题，因为与平均 1 毫秒和最大 10 毫秒相比，平均 STW 大约 20-30 毫秒，偶尔跳到 300+ 毫秒看起来真的很糟糕（正如 GC 制造商声称和测试的那样）确认）在 JVM 上暂停。

I must say it keeps me a little worried because there is a whole bunch of applications where GC pauses matter a lot.我必须说这让我有点担心，因为有一大堆应用程序 GC 暂停很重要。 In fact they are one of key factors that decide whether specified technology (eg .NET, JVM, native, ...) should be considered viable for a task or purpose.事实上，它们是决定特定技术（例如 .NET、JVM、本机等）是否应被视为对某项任务或目的可行的关键因素之一。 It looks like latest GCs on JVM open new areas for Java and other JVM languages/technologies.看起来 JVM 上的最新 GC 为 Java 和其他 JVM 语言/技术开辟了新的领域。 Areas where we do not allow possibility that application will stop for 500ms or so because GC has to do its work whereas ~10ms maximum with ~1ms average is good enough.我们不允许应用程序停止 500 毫秒左右的区域，因为 GC 必须完成它的工作，而大约 10 毫秒的最大值和大约 1 毫秒的平均值就足够了。

What is the truth today?今天的真相是什么？ How does CLR GC compare to latest JVM GCs? CLR GC 与最新的 JVM GC 相比如何？ Are there any guarantees regarding STW pauses on CLR (it looks like JVM is going that direction)?是否有关于 CLR 上的 STW 暂停的任何保证（看起来 JVM 正在朝那个方向发展）？

2 个解决方案

In recent years a lot of features were added to C# (which is no 1 player in .NET world) to reduce GC pressure.近年来，C#（在 .NET 世界中排名第一）中添加了许多功能以减少 GC 压力。 It is indisputable that all these features enable us to build better and more efficient applications.无可争辩的是，所有这些功能都使我们能够构建更好、更高效的应用程序。 But regardless of language and VM (CLR, JVM) features being added over time a performant and non-blocking GC is the key performance factor for managed applications.但是，无论语言和 VM（CLR、JVM）特性如何随着时间的推移而添加，高性能和非阻塞 GC 是托管应用程序的关键性能因素。

On the other hand there is very little information about CLR GCs.另一方面，关于 CLR GC 的信息很少。 Are there any up to date sources to see how CLR GCs (4.8, Core 3.1, .NET 5) compare to latest JVM achievements?是否有任何最新来源可以查看 CLR GC（4.8、Core 3.1、.NET 5）与最新 JVM 成就的比较？ I could find some older sources which discussed CLR GC vs G1.我可以找到一些讨论 CLR GC 与 G1 的较旧来源。 But today G1 is no match for ZGC/Shenandoah and old sources do not show the reality as it is today.但是今天 G1 不是 ZGC/Shenandoah 的对手，旧的消息来源并没有像今天这样显示现实。 Considering there are no newer sources we could conclude that CLR GC metrics did not improve significantly since then.考虑到没有更新的来源，我们可以得出结论，从那时起，CLR GC 指标并没有显着改善。 But it would look like a real problem for .NET platform in 2020 because average STW around 20-30 ms with occasional jumps to 300+ ms look really bad when compared to 1ms average and 10ms maximum (as the GCs makers claim and test seem to confirm) pauses on JVM.但这对于 2020 年的 .NET 平台来说似乎是一个真正的问题，因为与平均 1 毫秒和最大 10 毫秒相比，平均 STW 大约 20-30 毫秒，偶尔跳到 300+ 毫秒看起来非常糟糕（正如 GC 制造商声称和测试的确认）在 JVM 上暂停。

I must say it keeps me a little worried because there is a whole bunch of applications where GC pauses matter a lot.我必须说这让我有点担心，因为有一大堆应用程序 GC 暂停很重要。 In fact they are one of key factors that decide whether specified technology (eg .NET, JVM, native, ...) should be considered viable for a task or purpose.事实上，它们是决定特定技术（例如 .NET、JVM、本机等）是否应被视为对某项任务或目的可行的关键因素之一。 It looks like latest GCs on JVM open new areas for Java and other JVM languages/technologies.看起来 JVM 上的最新 GC 为 Java 和其他 JVM 语言/技术开辟了新的领域。 Areas where we do not allow possibility that application will stop for 500ms or so because GC has to do its work whereas ~10ms maximum with ~1ms average is good enough.我们不允许应用程序停止 500 毫秒左右的可能性的区域，因为 GC 必须完成它的工作，而大约 10 毫秒的最大值和大约 1 毫秒的平均值就足够了。

Due to the inherent design differences, it's pretty likely that the JVM's latest Garbage Collectors will drastically outperform the CLR's.由于固有的设计差异，JVM 最新的垃圾收集器很可能会大大优于 CLR。 The main reason behind this is that the CLR by default handles memory slightly better, something which the JVM does suffer a little from.这背后的主要原因是默认情况下 CLR 处理内存稍微好一些，JVM 确实会受到一些影响。 As a result, there hasn't really been much pressure to make the GC in the CLR blazing fast, since a simple design suffices and does pretty well.因此，让 CLR 中的 GC 快速运行并没有太大的压力，因为简单的设计就足够了，而且效果很好。 By contrast the JVM does have a need for better GCs, and in fact might have the most advanced ones to date.相比之下，JVM 确实需要更好的 GC，而且实际上可能拥有迄今为止最先进的 GC。 Although this likely won't make the JVM orders of magnitude faster than the CLR, if you pit their GC's against each other the CLR will stand no chance at all, especially with newer JVM GCs like Z and Shenandoah.虽然这可能不会使 JVM 比 CLR 快几个数量级，但如果你让它们的 GC 相互对抗，CLR 将根本没有机会，尤其是对于 Z 和 Shenandoah 等较新的 JVM GC。