.net - 你能重现这个 64 位 .NET 4 GC 错误吗？

Question

更新:微软现在已经重现了这个错误并正在努力修复。

在评估 .NET 平台在低延迟软件开发方面的可行性时，我们发现了 .NET 4 并发工作站垃圾收集器中的一个严重错误，该错误可能导致应用程序一次挂起长达几分钟。

在我们的三台机器上，以下简单的 C# 程序导致 GC 泄漏内存，直到没有剩余内存为止，并且启动了一个庞大的 GC 循环，在回收 11Gb 堆的同时将程序停止了几分钟(!):

    static void Main(string[] args)
    {
        var q = new System.Collections.Generic.Queue<System.Object>();
        while (true)
        {
            q.Enqueue(0);
            if (q.Count > 1000000)
                q.Dequeue();
        }
    }

您需要在具有 .NET 4 的 64 位 Windows 操作系统上针对 x64 进行编译，并使用默认(交互式)延迟设置在默认(并发工作站)GC 下运行。

这是在这台机器上运行此程序时任务管理器的外观:



请注意，当此程序需要不超过 100Mb 的内存时，此处会泄漏 11Gb 的堆。

我们现在已经积累了大约十几个这个 bug 的 repros，用 F# 和 C# 编写，当大部分 gen0 幸存下来时，它似乎与 GC 写屏障中的一个 bug 有关。但是，微软尚未能够复制它。你可以吗？如果是这样，您能否尽可能准确地描述您的设置，以便我们可以尝试准确缩小此错误出现所需的条件。

Answer 1

我无法重现它。我在具有 4 gigs ram 的 x64 上进行了尝试，编译为 ANY。最大内存使用量约为 2.5 gigs。最大 GC 暂停时间约为 1084 毫秒。
这是我的 GC ETW 统计信息的输出。

您还可以按时间获取 GC 事件

您运行的类似跟踪输出可能有助于了解幕后发生的事情。
在 .NET 4.0 中有提供框架跟踪信息的 Windows 事件跟踪 (ETW)。这是 GC 特有的。 .
为了获得这些信息，有一个工具叫做 PerfView
以下是使用该工具获取 GC 信息的步骤

以管理员身份启动 cmd.exe，这需要收集 ETW 跟踪

启动您要跟踪的应用程序

发出命令“PerfMonitor.exe/process:4180 start”，其中 4180 是进程 ID

让应用运行一段时间

然后发出“PerfMonitor.exe stop”

获取报告“PerfMonitor.exe GCTime”的命令。这将生成一个报告并在浏览器中使用 GC 统计信息打开它。