c# - Microsoft Visual C# 2008 减少加载的 dll 的数量

Question

在 Visual C# 2008 Express Edition 中调试时如何减少加载的 dll 数量？

在调试器中运行可视 C# 项目时，由于 2GB 虚拟地址空间的碎片，我得到了 OutOfMemoryException，我们假设加载的 dll 可能是碎片的原因。

布莱恩·拉斯穆森，你成就了我的一天! :)

他提出的“禁用 Visual Studio 托管进程”解决了这个问题。

(有关更多信息，请参阅下面的问题发展历史)

---

嗨， 我需要将两个大型 int 数组加载到内存中，每个元素约 1.2 亿个(约 470MB)，并且都在一个 Visual C# 项目中。

当我尝试实例化第二个数组时，我得到了 OutOfMemoryException。

我确实有足够的总可用内存，在进行网络搜索后，我认为我的问题是我的系统上没有足够大的连续可用内存块。 但! - 当我在一个 Visual C# 实例中仅实例化一个数组，然后打开另一个 Visual C# 实例时，第二个实例可以实例化一个 470MB 的数组。 (编辑澄清:在上面的段落中，我的意思是在 Visual C# 的调试器中运行它)

任务管理器会按照您的预期显示相应的内存使用增加。 所以整个系统上没有足够的连续内存块不是问题。然后我尝试运行一个已编译的可执行文件，该可执行文件实例化两个也可以工作的数组(内存使用量 1GB)

总结:

Visual C# 中的 OutOfMemoryException 使用两个大 int 数组，但运行编译后的 exe 工作(内存使用量 1GB)，并且两个单独的 Visual C# 实例能够为我的大数组找到两个足够大的连续内存块，但我需要一个 Visual能够提供内存的 C# 实例。

---

更新:

首先特别感谢 nobugz 和 Brian Rasmussen，我认为他们的预测是正确的，即“进程的 2GB 虚拟地址空间的碎片化”是问题所在。

按照他们的建议，我使用 VMMap 和 listdlls 进行简短的业余分析，我得到:
* 为“独立”-exe 列出了 21 个 dll。 (可以工作并使用 1GB 内存的那个。)
* 为 vshost.exe 版本列出了 58 个 dll。 (调试时运行并抛出异常的版本仅使用500MB)

VMMap 显示调试器版本的最大可用内存块为 262,175,167,155,108MB。
所以 VMMap 说没有连续的 500MB block ，根据关于空闲 block 的信息，我添加了大约 9 个较小的 int 数组，它们加起来超过 1.2GB 的内存使用量并且确实有效。
因此，我想说我们可以称“2GB 虚拟地址空间的碎片化”是有罪的。

从 listdll 输出中，我创建了一个将十六进制数字转换为十进制的小型电子表格，以检查 dll 之间的空闲区域，我确实为 (21) dll 之间的独立版本找到了很大的可用空间，但对于 vshost-debugger-却没有。版本(58 个 dll)。我并不是说两者之间不能有任何其他东西，我不确定我在那里所做的是否有意义，但它似乎与 VMMaps 分析一致，而且似乎单独的 dll 已经将内存碎片化了调试器版本。

因此，如果我能够减少调试器使用的 dll 数量，或许一个解决方案。
1. 这可能吗？ 2. 如果是，我该怎么做？

Answer 1

您正在与虚拟内存地址空间碎片作斗争。 32 位版本的 Windows 上的进程有 2 GB 的可用内存。该内存由代码和数据共享。代码块是 CLR 和 JIT 编译器以及 ngen-ed 框架程序集。数据 block 是 .NET 使用的各种堆，包括加载程序堆(静态变量)和垃圾收集堆。这些 block 位于内存映射中的不同地址。空闲内存可供您分配数组。

问题是，一个大数组需要一 block 连续的内存。地址空间中的“空洞”，位于代码块和数据 block 之间，不足以让您分配如此大的数组。第一个孔通常在 450 到 550 兆字节之间，这就是您的第一个阵列分配成功的原因。下一个可用的孔要小得多。太小而无法容纳另一个大数组，即使您有一个简单的千兆字节可用内存，您也会得到 OOM。

您可以使用 SysInternals' VMMap 查看进程的虚拟内存布局。效用。好的诊断，但它不会解决你的问题。只有一个真正的修复，移动到 64 位版本的 Windows。也许更好:重新考虑您的算法，使其不需要如此大的数组。