CLR 4.0 中的垃圾收集改进答案

【问题标题】：Garbage collections improvements in CLR 4.0CLR 4.0 中的垃圾收集改进
【发布时间】：2011-07-21 17:50:36
【问题描述】：

最近我在运行Andrew Hunter on his blog "The Dangers of the Large Object Heap" 提供的针对 .NET 4 编译的示例，我得到了以下数字：

大块：分配 622Mb
大块，垃圾频繁集合：已分配 582Mb
仅限小块：分配了 1803Mb
有大块，大块不是增长：已分配 630Mb

如果针对 .NET 2.0 编译相同的代码，我得到的数字几乎与文章中提到的一样：

大块：分配 21Mb
大块，垃圾频繁集合：已分配 26Mb
只有很小块：已分配 1811Mb
大块，大块不增长：已分配 707Mb

如此显着改善的原因是什么？

代码针对 x86 平台编译并在 Windows 7 上运行

【问题讨论】：

标签： c# .net clr clr4.0

【解决方案1】：

CLR 团队的一些急需工作是改进的原因，但显然仍有改进的余地：

http://mitch-wheat.blogspot.com/2010/11/net-clr-large-object-heap.html

【讨论】：

【解决方案2】：

发生了一些变化，但这是一个保守的秘密，我找不到任何关于它的信息。我不会投入太多的股票。代码示例经过手动调整，以使 CLR 2 大对象堆看起来尽可能糟糕。即使是受到博文启发的算法的微小变化，也会产生非常大的影响。

【讨论】：

同意。这个问题是试图找出有什么区别，因为我认为没有任何一个呈现的变化会以这种方式影响数字。

【解决方案3】：

我可以想到微软可以对内存分配器做一些简单的事情，这些事情可以在不进行大修的情况下大大减少 LOH 碎片，例如将分配大小四舍五入到 4K 等倍数。鉴于最小的非静态 LOH 对象为 85K，这最多会损失 5% 的有用空间，但会减少不同大小的对象和间隙的数量。顺便说一句，我真的不相信将所有大对象强制到 LOH 的价值（也许，有一种方法可以指定何时创建对象是否应该进入 LOH）。一旦达到 2 级，我可以理解将小对象与大对象区分开来的一些价值，但有足够多的情况下，大对象被创建和放弃，迫使它们进入 2 级似乎适得其反。

【讨论】：

双精度数组以比 85K 小得多的大小放入 LOH，但四舍五入仍然是一个很好的理想状态
我对微软的一些决定感到非常困惑。显然，双精度数组被推送到 LOH 的原因是因为 LOH 对象在 8 字节边界上对齐，而普通堆对象不是。我认为对不大于指针的特殊情况对象有意义，以便它们直接存储在堆描述符表中（代替指针），然后将所有堆对象四舍五入到下一个缓存行大小，无论它们是否包含任何双精度值。