CLR 4.0 中的垃圾收集改进
最近我正在运行 Andrew Hunter 在他的博客“大对象堆的危险” 上针对 .NET 4 进行了编译，我得到了以下数字：
对于大块：分配 622Mb
块大，垃圾频繁 集合：仅分配 582Mb
小块：分配1803Mb
大块，大块不是 增长：已分配 630Mb
如果针对 .NET 2.0 编译相同的代码，我几乎得到了文章中提到的数字：
对于大块：分配 21Mb
块大，垃圾频繁 集合：分配了 26Mb
只有很小 块: 1811Mb 分配
大 块，大块不增长： 已分配 707Mb
如此显着的改善的原因是什么？
代码针对 x86 平台编译并在 Windows 7 上运行
Recently I was running the example provided by Andrew Hunter on his blog "The Dangers of the Large Object Heap" compiled against .NET 4 and I got the following numbers:
With large blocks: 622Mb allocated
With large blocks, frequent garbage
collections: 582Mb allocated
Only
small blocks: 1803Mb allocated
With
large blocks, large blocks not
growing: 630Mb allocated
If the same code is compiled against.NET 2.0 I got almost the numbers mentioned in article:
With large blocks: 21Mb allocated
With large blocks, frequent garbage
collections: 26Mb allocated
Only small
blocks: 1811Mb allocated
With large
blocks, large blocks not growing:
707Mb allocated
What is the cause of such dramatical improvement?
Code is compiled for x86 platform and is run on Windows 7
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
CLR 团队急需的一些工作是改进的原因，但显然仍有改进的空间：
http://mitch-wheat.blogspot.com/2010/11/net-clr-large-object-heap.html
Some much needed work from the CLR team is the reason for the improvements, but apparently there is room for improvement still:
http://mitch-wheat.blogspot.com/2010/11/net-clr-large-object-heap.html
有些事情发生了变化，但这是一个严格保密的秘密，我什么也找不到。我不会投入太多股票。该代码示例经过手动调整，以使 CLR 2 大型对象堆看起来尽可能糟糕。即使是算法上的一个小变化，也许是受到博客文章的启发，也会产生非常大的影响。
Something changed but it is a well kept secret, I can find nothing about it. I wouldn't put too much stock into it. The code sample was hand-tuned to the make the CLR 2 large object heap look as bad as possible. Even a small change in the algorithm, perhaps inspired by the blog post, will have very large effects.
我可以想到 Microsoft 可以对内存分配器做一些简单的事情，这些事情可以大大减少 LOH 碎片，而无需进行重大修改，例如将分配大小舍入到某个倍数（例如 4K）。鉴于最小的非静态 LOH 对象为 85K，这最多表示有用空间损失 5%，但会减少不同大小的对象和间隙的数量。顺便说一句，我真的不相信强制所有大对象进入 LOH 的价值（也许与在创建对象时指定是否应该进入 LOH 的方法相反）。我可以理解，一旦小对象达到 2 级，将小对象与大对象分开是有价值的，但是有足够多的情况，大对象被创建并放弃，迫使它们达到 2 级似乎会适得其反。
I can think of some easy things Microsoft could have done to the memory allocator that would have greatly reduced LOH fragmentation without major overhaul, such as rounding allocation sizes up to some multiple like 4K. Given that the smallest non-static LOH objects were 85K, that would represent at most a 5% loss of useful space, but would reduce the number of different-sized objects and gaps. BTW, I'm really unconvinced of the value forcing all big objects to the LOH (as opposed to, perhaps, having a means of designating when an object is created whether it should go to the LOH or not). I can understand some value in separating small objects from big ones once they reach Level 2, but there are enough cases where big objects get created and abandoned that forcing them to level 2 seems counterproductive.