繁体 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 4 2 c#/ .net/ garbage-collection/ jvm/ clr

近年来，C#（在 .NET 世界中排名第一）中添加了许多功能以减少 GC 压力。 无可争辩的是，所有这些特性都使我们能够构建更好、更高效的应用程序。 但无论语言和 VM（CLR、JVM）特性如何随着时间的推移而添加，高性能和非阻塞 GC 是托管应用程序的关键性能因素。

最近在 JVM 世界中出现了两个新的 GC，它们似乎提供了非凡的指标。 有一些来源（包括作者）提供了关于这些 GC 的基准和技术见解。 我们可以了解到，“承诺”的最大 STW（停止世界）间隔不再超过 10 毫秒，并且无论堆大小如何，通常平均都在 1 毫秒以下。 还有一些测试表明，新的 GC 开销得到了很好的平衡，不会对应用程序吞吐量产生负面影响，同时大幅减少（减少 10 倍或更多）STW 暂停。

另一方面，关于 CLR GC 的信息很少。 是否有任何最新来源可以查看 CLR GC（4.8、Core 3.1、.NET 5）与最新 JVM 成就的比较？ 我可以找到一些讨论 CLR GC 与 G1 的较旧来源。 但是今天 G1 不是 ZGC/Shenandoah 的对手，旧的消息来源并没有像今天这样显示现实。 考虑到没有更新的来源，我们可以得出结论，从那时起，CLR GC 指标并没有显着改善。 但这对于 2020 年的 .NET 平台来说似乎是一个真正的问题，因为与平均 1 毫秒和最大 10 毫秒相比，平均 STW 大约 20-30 毫秒，偶尔跳到 300+ 毫秒看起来真的很糟糕（正如 GC 制造商声称和测试的那样）确认）在 JVM 上暂停。

我必须说这让我有点担心，因为有一大堆应用程序 GC 暂停很重要。 事实上，它们是决定特定技术（例如 .NET、JVM、本机等）是否应被视为对某项任务或目的可行的关键因素之一。 看起来 JVM 上的最新 GC 为 Java 和其他 JVM 语言/技术开辟了新的领域。 我们不允许应用程序停止 500 毫秒左右的区域，因为 GC 必须完成它的工作，而大约 10 毫秒的最大值和大约 1 毫秒的平均值就足够了。

今天的真相是什么？ CLR GC 与最新的 JVM GC 相比如何？ 是否有关于 CLR 上的 STW 暂停的任何保证（看起来 JVM 正在朝那个方向发展）？

2 个解决方案

近年来，C#（在 .NET 世界中排名第一）中添加了许多功能以减少 GC 压力。 无可争辩的是，所有这些功能都使我们能够构建更好、更高效的应用程序。 但是，无论语言和 VM（CLR、JVM）特性如何随着时间的推移而添加，高性能和非阻塞 GC 是托管应用程序的关键性能因素。

另一方面，关于 CLR GC 的信息很少。 是否有任何最新来源可以查看 CLR GC（4.8、Core 3.1、.NET 5）与最新 JVM 成就的比较？ 我可以找到一些讨论 CLR GC 与 G1 的较旧来源。 但是今天 G1 不是 ZGC/Shenandoah 的对手，旧的消息来源并没有像今天这样显示现实。 考虑到没有更新的来源，我们可以得出结论，从那时起，CLR GC 指标并没有显着改善。 但这对于 2020 年的 .NET 平台来说似乎是一个真正的问题，因为与平均 1 毫秒和最大 10 毫秒相比，平均 STW 大约 20-30 毫秒，偶尔跳到 300+ 毫秒看起来非常糟糕（正如 GC 制造商声称和测试的确认）在 JVM 上暂停。

我必须说这让我有点担心，因为有一大堆应用程序 GC 暂停很重要。 事实上，它们是决定特定技术（例如 .NET、JVM、本机等）是否应被视为对某项任务或目的可行的关键因素之一。 看起来 JVM 上的最新 GC 为 Java 和其他 JVM 语言/技术开辟了新的领域。 我们不允许应用程序停止 500 毫秒左右的可能性的区域，因为 GC 必须完成它的工作，而大约 10 毫秒的最大值和大约 1 毫秒的平均值就足够了。

今天的真相是什么？ CLR GC 与最新的 JVM GC 相比如何？ 是否有关于 CLR 上的 STW 暂停的任何保证（看起来 JVM 正在朝那个方向发展）？

由于固有的设计差异，JVM 最新的垃圾收集器很可能会大大优于 CLR。 这背后的主要原因是默认情况下 CLR 处理内存稍微好一些，JVM 确实会受到一些影响。 因此，让 CLR 中的 GC 快速运行并没有太大的压力，因为简单的设计就足够了，而且效果很好。 相比之下，JVM 确实需要更好的 GC，而且实际上可能拥有迄今为止最先进的 GC。 虽然这可能不会使 JVM 比 CLR 快几个数量级，但如果你让它们的 GC 相互对抗，CLR 将根本没有机会，尤其是对于 Z 和 Shenandoah 等较新的 JVM GC。