.NET 托管堆何时以及如何被交换？

Question

我的小型压力测试在循环中分配随机长度数组（每个 100..200MB），在 64 位 Win7 机器和 32 位 XP（在 VM 中）上显示不同的行为。两个系统通常首先分配尽可能多的数组以适合 LOH。然后 LOH 变得越来越大，直到可用的虚拟地址空间被填满。到目前为止的预期行为。但是，根据进一步的请求，两者的行为不同：

虽然在 Win7 上抛出了 OutOfMemoryException (OOM)，但在 XP 上，堆似乎增加了，甚至交换到了磁盘 - 至少没有抛出 OOM。 （不知道，这是否与 XP 在虚拟框中运行有关。）

问题： 运行时（或操作系统？）如何决定，对于托管内存分配请求，如果它太大而无法分配，是否会生成 OOM 或大型对象堆正在增加 - 最终甚至交换到磁盘？ 如果被交换，OOM 是什么时候发生的呢？

IMO 这个问题对所有生产环境都很重要，可能会处理更大的数据集。不知何故，知道系统宁愿在这种情况下（通过交换）显着减慢速度而不是简单地抛出 OOM 感觉更“安全”。至少，它应该是确定性的，对吧？

@Edit：该应用程序是 32 位应用程序，因此在 Win 7 上以 32 位模式运行。

Answer 1

正常规则适用，托管进程不会被 Windows 内存管理器区别对待。内存块的最终来源是 Windows 内存管理器。如果它在虚拟内存地址空间中找不到适合请求的内存分配的空洞，则 VirtualAlloc() 调用失败，CLR 生成 OOM。

交换行为也是如此，如果 RAM 中的页面需要映射其他进程的页面，甚至是同一进程的页面，那么它们将被交换出去。这与 OOM 无关。

您不能假设它在 XP 上的工作方式与在 Win7 x64 上的工作方式完全相同。在构建面向 AnyCPU 的程序时在 x64 上获得 OOM 是非常不寻常的，64 位操作系统具有非常大的虚拟内存地址空间。上限由页面文件的最大大小设置。一个 32 位程序将在 WOW 仿真层中运行，如果您使用 Editbin.exe 设置 LARGEADDRESSAWARE 选项位，它可以有 4 GB 的地址空间。

您可以使用 SysInteral 的 VMMap 实用程序来查看进程的地址空间是如何划分的。