CLR 4.0中的垃圾收集改进

Question

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

  

使用大块：分配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）。一旦达到第2级，我就能理解将小物体与大物体分开的一些价值，但是有足够多的情况下，大物体被创造和放弃，迫使它们达到2级似乎适得其反。