ptmalloc实现代码说明

Question

我期待了解动态内存管理在 GNU/Linux 系统中的低级工作原理（也就是 ptmalloc 的工作原理）。

当然，我已经阅读了代码，但我有很多疑问。我或多或少地了解数据结构，但我有很多信息泄漏！

我的问题是，是否有人知道任何详细解释实施的资源。例如，我读过诸如“通过破坏堆来理解堆”或“Malloc Malleficarum”系列和后期系列之类的论文。他们做得很好，但当然，他们更专注于开发而不是解释许多实现细节。

如果您不了解任何资源，这里是我的一些问题。

• 什么是真正的竞技场？在 heap_info 结构中的变量 ar_ptr 的代码中，有一条注释说“这个堆的竞技场”，所以竞技场不能是一个堆（就像到处都说的那样)。

• 为什么在 heap_info 结构中没有 next 指针而有 prev 指针？是因为ma​​in_arena吗？ ma​​in_arena 是什么？

• 每个 heap_info 结构都可以有多个 arena（指向不同的 ma​​lloc_state 结构）？

• 什么时候创建新闻竞技场，什么代码处理它？我读过当请求存储数据的竞技场被锁定时会创建新的竞技场（因为进程或进程线程正在使用它），并且我还读到每个进程线程都有不同的竞技场。重要的是您是否知道处理这些情况的代码。

• 我也不明白人们何时说所有内存操作都来自顶部块或最狂野的块。你知道我在哪里可以找到这段代码吗？

顺便说一句，我不想​​深入了解互斥锁的细节。

我正在审查 glibc 2.12.1 中的 ptmalloc 实现。我想做一些关于所有东西的整体结构的图表，所以我需要了解这些东西！

谢谢。

Answer 1

堆基本上分为许多小区域，它们独立地满足一个或多个分配的对象。一个这样的区域可能被称为竞技场或区域。主要是堆是满足对象的竞技场集合，要求可以在单个操作中释放一个竞技​​场。为了实现这一点，整个 arena 被分配为单个连续的内存地址范围。

竞技场或区域之间的区别是灰色的。我不确定 Linux，但一个例子是 Cavium 网络的真实世界多核网络处理器系列，称为 Octeon。它将分配的内存视为竞技场或区域，不同之处在于区域可以分配固定相等大小的对象，而竞技场可以有不同大小的对象。在竞技场的情况下，这自然会导致碎片化。但我无法确认 Linux 是否也是这种情况。

Region based memory management

Answer 2

好的，我已经进行了一些研究，其中很多问题我都有答案。

• arena 是存储进程的所有动态数据的内存区域。简而言之，arena就是过去称为堆的内存结构。鉴于现在（使用多线程的东西）你希望每个进程拥有多个堆，你可以通过创建一个叫做 arena 的东西来处理它，但是这个 arena 只不过是一个堆。 heap_info 结构仅管理一个进程的多个现有领域。

• 我不知道为什么只有一个 prev 指针。我所知道的是，通常情况下，所有动态数据都存储在 ma​​in_arena 中，它是为该进程创建的 arena。我不知道在什么情况下不使用 ma​​in_arena，我知道的是如果内存块中的 size 字段具有 NON_MAIN_ARENA 位设置，则不使用 ma​​in_arena，算法通过 heap_for_ptr() 清除该内存块指针的 20 个较低有效位来获取新的 arena 地址> 宏。综上所述，正常情况下，ma​​in_arena会一直使用。

• 是的，正如我所说，每个 heap_info 结构都可以有多个领域。这是因为锁争用。如果您有足够的空闲时间，可以在 [1] 中阅读相关内容。

• 我不记得这个了。但事实是，如果竞技场正在使用中，被锁定，就会创建一个新的竞技场。搜索对类似于 new_arena() 或 new_heap() 的函数的任何调用。我记得函数名和那个差不多。

• 我认为这只是意味着一开始堆的所有内存空间都是top chunk（或wild chunk），所以当进程需要新的内存请求时，这个top chunk会被分割和碎片化.所以这一切都从顶部的块开始。

不想浮夸，我想，三个月后，我的答案是更适合我的问题的答案，所以我把它作为正确的答案。另一方面，感谢所有其他答案。他们真的很有帮助。

顺便说一句，我把所有这些研究都写在了一篇论文中，但鉴于它是西班牙语的，我认为它在这里不会有用，我不知道它是否会被视为垃圾邮件。 [2]

[1]http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.4439

[2] 这里有论文：http://overflowedminds.net/papers/newlog/linux_heap_exploiting_revisited.pdf