在.NET上,64位平台上的大对象堆碎片与32位相比是一个问题吗？

我广泛使用基于并行数组(SCG.SortedList看起来像Outer>)的嵌套数据结构和一个复制结构的计算引擎.结构的大小可能非常不同,其中许多都是LOH,因为 - 即使它们已经嵌套 - 内部或外部的长度足够长,值大多为双倍(对于双倍,限制为1000个元素)每个数组后,它进入LOH,至少在x86上).

嵌套数据结构的用例是在长时间运行的过程中累积高频数据.我可以使用它作为缓冲区来聚合数据,只保留聚合所需的最小窗口(通过删除较旧的内部列表并修剪外部列表),但这种复制/修剪本身可能会产生LOH碎片问题并占用更多内存而不是保存它.

在深入阅读LOH碎片后,我可以推断,在我的情况下,我会有LOH碎片,因为在我的过程/计算中经常发生的事情正是在描述中,例如,一篇关于Andrew Hunter的LOH碎片的伟大文章:创造,成长通过随机增量,复制数组......

但是,我无法理解64位平台上的LOH碎片是否存在问题？在对同一篇文章的最后评论中,一位评论者认为,在64位平台上,LOH碎片几乎不是问题,因为地址空间太大,实际上很难用尽它,而内存空洞/空页不支持通过真实记忆.(另一个选择是MS在设计GC时失败了).

有些专家可以确认评论中的陈述是否适用于.NET托管内存？在大多数情况下,由于极大的地址空间,64位系统上的LOH碎片是不是应该担心？在写这个问题时,我已经找到了对C++的确认,所以这个问题专门针对.NET中的托管内存.

第二个问题是它如何适用于在64位系统上运行的32位进程？这两者是否同样适用,或者如果存在LOH碎片,32位进程可能会快速耗尽内存？(例如,对于Excel加载项,即使在64位系统上,由于传统的加载项很长时间,我也被限制为32位架构)

链接文章的评论如下:

页面缓存发布者:TruePath发布日期:2011年11月24日星期四上午6:50消息:

您使用的是不支持64位寻址的旧操作系统/ CPU(或win 7的廉价版本),或者MS从根本上无法正确利用64位寻址.

Win 7终极版允许一个进程地址高达192演出,雪豹16TB和Linux 32艾字节.你永远不会真实地咀嚼LOH中的整个地址空间.因此,MS为分配实施的策略听起来像是正确的策略,而且只是一些人为的限制正在阻碍.

请记住,因为您已经分配了一页内存并不意味着操作系统必须始终使用一页RAM来备份.操作系统完全可以自由地将页面交换到磁盘或保留空白页面.LOH应该为每个对象分配整数个psges(4K).当GC释放LOH中的对象时,应该将分配给它的页面返回给操作系统,这样它们就不再需要任何后备存储,也不会占用磁盘空间或使页面分配结构变形.

实际上,64字节系统上的LOH应该比规范堆更快且资源更少,因为没有对象被复制并且所有对象都获得整数页.与regulsr堆不同,碎片不是真正的问题,因为硬件支持的页表会为您处理.实际上,在达到虚拟内存限制之前,从不GC到LOH可能是最佳的.

确实,这样的策略最终会将LOH的大部分内容写入磁盘,但这会在第二个并发进程中发生.只要你没有在LOH中分配对象并且弄脏他们的页面的速度比你的磁盘写的速度快,你就不应该看到任何减速,除了磁盘IO的小竞争和较大的OS页面映射的小影响.系统不会崩溃,因为大多数页面确实是免费的,因此永远不会再从磁盘读回.如果LOH中没有GC标记对象,则不会发生GC的错误页面访问.因此,页面缓存使用的LIFO算法是一个相当不错的GC,它可以为某些磁盘写入和(可能)偶尔读取交换GC开销.

我想将LOH中的对象的GC元数据和任何嵌入式指针保存在与其余数据不同的页面上会更好(如果你愿意,它可以在它之前,页面的其余部分可以用于其他堆/ metadata)因此GC仍然可以释放LOH中的页面而不会触发任何不需要的页面加载.由于LOH中的对象几乎没有任何指针成员/元素(或者都是指针并且必须由GC扫描),因此可以将这些对象与数据隔离并获得两全其美:无磁盘写入且无错误页面加载对于GC.

更新:假设存在LOH碎片.问题是关于内存地址空间碎片对x64平台上的实际内存的影响,以及它在x64上运行的32位进程中的工作方式.

问题不在于如何避免它/处理它以及使用什么数据结构(文章讨论了这个).我已经做了很多测试,发现嵌套排序列表比不可变结构快5倍以上,并且通过在内部列表中使用键delta(uint16 vs int64)将我的数据压缩c.40%,而IntMap/AVL树每个键/值对占用70/50字节的开销.非常逼真的1000万对我更喜欢嵌套SL.因此,预期/可能的LOH碎片是为速度和天真的内存压缩付出的代价.我无法全面测试但由于碎片导致多少内存实际上"泄漏",但从我读过的内容中我有理由怀疑是否存在任何泄漏.