tem*_*def 17 algorithm memory-management
在阅读了关于Windows内存分配器看似堕落行为的这个问题之后,回想一下本文关于构建快速实现实现的最坏情况输入的问题,我开始想知道:是否可以构建一个程序,给出一个黑盒内存分配器,即使系统中仍有足够的内存,强制分配器使分配请求失败？也就是说,是否可以采用黑盒内存分配器并强制它失败？
我知道这可以通过以棋盘图案分配和释放内存来强制进行大规模碎片来完成,因此在我看来,理想的解决方案会导致失败时分配的总字节数最少.对于启发了这一点的原始帖子,如果内存分配器有内部错误,理论上可能会导致分配零字节的失败.
关于如何做到这一点的任何想法/想法？
取决于“足够的可用内存”的含义。对于简单的碎片“攻击”：
进行数十亿次small分配，直到失败[*]。
现在，按照地址[**]的顺序对它们进行排序。
免费 100 个备用分配。
尝试分配100*small字节。
分配器很可能无法找到连续内存来满足这一要求。如果它具有一定的small页面大小，并且与物理内存相比有足够的虚拟地址空间，那么它可能能够重新安排事情来做到这一点 - 但这需要 MMU 的功能以及分配器的任何反碎片策略。
如果“足够的可用内存”是指large以前是连续块的内存块，已被分成多个分配，所有这些分配都已被释放，现在分配器将其视为单独的块，因此无法分配large字节那么不，我认为您不能强制任意块盒分配器无法合并块。某些分配器或其他分配器可能会比 Windows 在另一个问题中所做的工作多得多，以保证相邻的空闲块始终合并。
[*] 可能的问题 - 过度提交内存分配器可能不会失败，您只是遇到段错误或者您的进程被终止。在此类系统上，您可能需要跟踪有多少内存可用。
[**] 可能出现的问题 - 在 C 和 C++ 中，operator<不保证可以正常工作。但几乎在所有系统上都是如此，在 C++ 中也是如此std::less。