这是一个多么好的内存分配器？答案

【问题标题】：How good a memory allocator is this?这是一个多么好的内存分配器？
【发布时间】：2012-01-15 12:15:15
【问题描述】：

如您所知，mmap 和 malloc 在具有地址空间布局随机化的系统上是不确定的。为了使我的内存分配具有确定性，我使用mmap 来保留一个非常大的地址空间（在 64 位系统上），没有交换空间，即使用 MAP_NORESERVE。然后当我需要内存时，我通过在该地址空间范围内使用 MAX_FIXED 执行 mmap 分配 10 MB 的空间。因此，分配的内存线性增长。

当我需要free 内存时，我只需使用munmap 取消映射它。此外，我没有重新利用未映射的地址空间，而是继续提前分配。我想这并不会真正影响任何事情，因为我的地址空间（使用mmap 和 MAP_NORESERVE 分配）无论如何都非常大。

现在的问题是，这是一个多么好的内存分配器。它当然不是一个非常聪明的，因为它不能分配小块内存，因为通过mmap 你分配了至少 4096 字节的内存，但我想它仍然是一个相当可行的解决方案。你怎么看？

此外，如果进程仅分配因子 4096 的内存，该怎么办。在那种情况下，我认为这种方法不会逊于malloc。

编辑

请注意，我说的是关于两个相同冗余进程的确定性。一个是从另一个分叉出来的，所以它使用 MAP_NORESERVE 获取映射区域的初始地址，就像我之后做的 fork 一样。

【问题讨论】：

我想说的主要问题应该是：为什么你需要你的应用程序的内存是一个块？
这有什么意义？为什么你认为这会更“确定”？
ThiefMaster，在我的问题中添加了为什么我需要这个。
MAP_NORESERVE?你不是说MAP_SHARED吗？
Darkdust，不，我说的是 MAP_NORESERVE，我的意思是 MAP_NORESERVE。另外我说的是私有分配的内存，因此是 MAP_PRIVATE，而不是 MAP_SHARED。

标签： c linux gcc x86-64

【解决方案1】：

使我的内存分配具有确定性

一个更简单的解决方案可能只是disable ASLR。

这是一个多么好的内存分配器。

这在很大程度上取决于您的质量标准。正如另一个答案指出的那样，它不是一个很好的通用分配器。但是，通用分配器通常不需要确定性。

大概你有这样的要求，可能还有其他一些（但未说明的）要求。

由于您让我们对您实际尝试做的事情一无所知，我们无法告诉您您所做的是否好。

【讨论】：

我刚刚注意到这个问题来自谁。我已经在心里记下了不回答任何 MetallicPriest 的问题，因为它们总是相当低级、非常奇怪并且非常不明确。

【解决方案2】：

不好。迟早你会用完虚拟内存。迟早取决于您的进程分配和释放多少，但无论如何，它肯定不适合长时间运行的守护进程。

但是这种确定性要求很奇怪。即使您的内存分配是确定性的，它也取决于输入。如果流程以稍微不同的顺序执行某些操作，则结果会有所不同。
如果他们做的每件事都完全相同，他们怎么会是多余的？如果一个会崩溃，那么另一个也会做同样的事情。

【讨论】：

ugoren，就像我说的，它是一个 64 位系统，我们几乎拥有无限的地址空间，就物理内存和页面交换而言，它不像我们没有释放（释放）内存，但只是没有像 malloc 那样精细。这是我猜的唯一区别。如果说，我们有一个进程只分配 4096 的内存，那么我认为这种方法甚至比 malloc 更好。你说什么？
没有什么是无限的。在 64 位系统中，耗尽内存可能需要更多时间。此外，进程地址空间很大，但不是 2^64 字节 - 它要小得多。它对于任何合理的事情都足够大，但不足以继续丢弃虚拟内存。
没有必要，如果一个崩溃，另一个会！我的意思是你可能有一个软错误，它会破坏一个进程的数据，但不会破坏另一个进程的数据。而且没有人抛出记忆。我确实释放它。