CLR 4.0中的垃圾收集改进

Question

最近我运行了Andrew Hunter在其针对.NET 4编写的博客“大对象堆的危险”中提供的示例，我得到了以下数字：

大块：分配622Mb
对于大块，频繁的垃圾收集：分配582Mb
只有小块：分配1803Mb
对于大块，大块不增长：分配630Mb

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

大块：分配21Mb
对于大块，频繁的垃圾收集：分配26Mb
只有小块：分配1811Mb
对于大块，大块不增长：分配707Mb

这种戏剧性改善的原因是什么？

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

Answer 1

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

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

Answer 2

有些事情发生了变化，但这是一个保密的秘密，我什么都找不到。 我不会把太多的股票投入其中。 手动调整代码示例使CLR 2大对象堆看起来尽可能糟糕。 即使算法的微小变化（可能受到博客文章的启发）也会产生非常大的影响。

Answer 3

我可以想到微软本可以对内存分配器做一些简单的事情，这样可以大大减少LOH碎片而不需要进行大修，例如将分配大小舍入到像4K这样的多个分区。 鉴于最小的非静态LOH对象是85K，这将最多占用有用空间的5％，但会减少不同大小的对象和间隙的数量。 顺便说一下，我真的不相信强迫所有大型物体进入LOH的价值（相反，或许，有一种方法可以指定何时创造一个物体，无论它是否应该转到LOH）。 一旦达到Level 2，我就能理解将小物体与大物体分开的一些价值，但是有足够的情况下，大物体被创造和放弃，迫使它们达到2级似乎适得其反。