簡體 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 9 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。