没有页面文件的Windows XP内存管理 - 后果是什么.堆碎片?

Mat*_*t C 10 c++ heap winapi virtual-memory

我一直在研究一个在Windows XP嵌入式系统上的应用程序中看到的相当难以捉摸的错误.

我们已经将错误缩小到指向应该指向内存块的指针,而是指向NULL.由于内存被分配了一个未经检查的malloc(..)调用,我的直觉说malloc失败并返回NULL(虽然我们现在正在寻找其他可能性,例如竞争条件可能会无意中改变指针).这是一个本机C++应用程序.崩溃对于追踪这个原因有点复杂,主要是因为我们只有事后的崩溃转储和故障表现在我们没有源的第三方库中,在另一个线程上.娱乐时间 :)

我的问题集中在记忆耗尽的可能性上.重要的是我们运行的XP Embedded系统的'pagefile被禁用了.

所以,我有三个问题; 如果有人能为我澄清这些,那就太好了:

  • 主要是,没有分页文件会有什么影响?这是否意味着当堆增长时,操作系统需要立即找到并分配新内存,即使这些空闲块未立即使用?我已经看到了一些关于它的轶事提及,但是找不到任何具体关于禁用页面文件的效果的具体内容.

  • 为什么Microsoft决定在Windows Vista之前默认启用低碎片堆?在Windows XP上为您的进程启用LFH是否存在危险?

  • WinDbg在"外部碎片"和"虚拟地址碎片"之间有什么区别?

WinDbg报告受影响的堆上的堆统计信息,如下所示:

Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast
                  (k)     (k)    (k)     (k) length      blocks cont. heap
04770000 00001002 1621948  94844 1608284  102    6  8068    6      2   L 

  Virtual address fragmentation  94 % (8068 uncommited ranges)
Run Code Online (Sandbox Code Playgroud)

MSa*_*ers 4

与 Linux 不同,在 Windows 上分配是一种承诺。您能够写入分配的内存。性能可能很糟糕,但 Windows 不需要 OOM 杀手。

如果没有分页文件,则承诺必须由 RAM 支持。然而未使用的内存(例如仅在程序初始化期间使用的内存)仍在耗尽 RAM,因为它无法调出。因此,用于做出承诺的 RAM 较少,但需求却更大。

LFH 破坏了有缺陷的程序,或者更好地说:有缺陷的程序可能会在 LFH 存在的情况下显示其错误。微软对损坏的程序非常友好,让 LFH 选择加入 XP 就是他们包容行为的典型例子。