我应该采取哪些预防措施来创建一个不会调用未定义行为的内存池？

Question

我最初的问题是，在一个项目中，我有几个共享生命周期的对象（即，一旦我释放其中一个，我将释放它们全部），然后我想分配一个内存块。我有三种不同对象类型的数组，struct foo、void * 和 char。一开始我想malloc()这样一个块：

// +---------------+---------+-----------+---------+---------+
// | struct foo[n] | padding | void *[m] | padding | char[o] |
// +---------------+---------+-----------+---------+---------+

但是……如果不调用未定义的行为，我怎么能做到这一点？即，尊重类型别名规则，对齐方式......如何正确计算内存块大小，声明内存块（及其有效类型），以及如何正确获取指向其中所有三个部分的指针？

（我确实知道我可以 malloc() 3 个块，这将导致三个 free()，但我想知道如何在仍然表现良好的情况下使用单个块。）

我想将我的问题扩展到一个更普遍的问题：应该采取哪些预防措施来为任意大小和对齐的对象实现memory pool，同时保持程序的良好运行？ （假设可以在不调用未定义行为的情况下实现它。）

Answer 1

无论你多么努力，在纯 C 中实现 malloc 是不可能的。

您总是在某些时候违反严格的别名。为免生疑问，使用没有动态存储持续时间的char 缓冲区也将违反严格的别名规则。您还必须确保返回的任何指针都具有适当的对齐方式。

如果您乐于将自己束缚在特定平台上，那么您不妨转向 malloc 的特定实现来寻​​求灵感。

但是为什么不考虑编写一个调用malloc 并建立一个其他已分配对象表的存根函数呢？你甚至可以实现某种观察者/通知框架。另一个起点可能是用 C 编写的著名垃圾收集器。

Answer 2

通过了解 3 种类型中 union 的大小，可以进行更有效的分配。

union common {
  struct foo f;
  void * ptr;
  char ch;
};

void *allocate3(struct foo **f, size_t m, void **ptr, size_t n, char **ch,
    size_t o) {
  size_t u_sz = sizeof (union common);
  size_t f_sz = sizeof *f * m;
  size_t f_cnt = (f_sz + u_sz - 1)/u_sz;
  size_t p_sz = sizeof *ptr * n;
  size_t p_cnt = (p_sz + u_sz - 1)/u_sz;
  size_t c_sz = sizeof *ch * o;
  size_t c_cnt = (c_sz + u_sz - 1)/u_sz;
  size_t sum = f_cnt + p_cnt + c_cnt;
  union common *u = malloc(sum * u_sz);
  if (u) {
    *f = &u[0].f;
    *ptr = &u[f_cnt].ptr;
    *ch = &u[f_cnt + c_cnt].ch;
  }
  return u;
}

这样，3 个数组中的每一个都从 union 边界开始，因此可以解决对齐问题。通过将每个数组的空间调整为union 大小的倍数，与first answer 相比，浪费的空间更少，但仍符合 OP 发布的目标。

有点浪费是struct foo 很大，而o 很小。可以使用以下作为进一步的改进。最后一个之后不需要填充 数组。

malloc((f_cnt + p_cnt) * u_sz + c_cz);

---

进一步考虑压缩分配。每个后续的“联合计数元素”都可以使用省略早期类型的不同联合，依此类推。当到达终点时——这就是上面想法的要点，最后一个数组只需要依赖于最后一个类型。这使代码更复杂（容易出错），但确实提高了空间效率，而不会出现问题等。一些编码想法如下

union common_last2 {
  // struct foo f;
  void * ptr;
  char ch;
};

size_t u2_sz = sizeof (union common_last2);
size_t p_cnt = (p_sz + u2_sz - 1)/u2_sz;

... malloc(f_cnt*usz + p_cnt*u2_sz + c_cz);

*ch = tbd;

Answer 3

正如另一个答案中所说，您不能在 C 本身中重新实现 malloc 。原因是没有malloc就无法生成没有有效类型的对象。

但是对于您的应用程序，您不需要这个，您可以使用malloc 或类似的，见下文，拥有一大块内存没有问题。

如果您有这么大的块，您必须知道如何将对象放置在该块中。这里的主要问题是对齐，您必须将所有对象放置在符合其最小对齐要求的边界上。

从C11开始，可以使用_Alignof操作符获得类型的对齐，使用aligned_alloc可以请求过度对齐的内存。

将所有这些放在一起，内容如下：

• 计算所有类型对齐的 lcm
• aligned_alloc 请求与该值对齐的足够内存
• 将所有对象放在该对齐的倍数上

如果您从通过void* 指针接收的无类型对象开始，那么别名就不是问题。该大对象的每个部分都有您写入的有效类型，请参阅我最近的blog entry。

C标准的相关部分是6.5 p6：

访问其存储值的对象的有效类型是 对象的声明类型，如果有的话。87) 如果一个值被存储到 没有通过具有类型的左值声明的类型的对象 不是字符类型，则左值的类型变为 该访问和后续的对象的有效类型 不修改存储值的访问。如果一个值被复制 使用 memcpy 或 memmove 进入没有声明类型的对象，或者是 复制为字符类型的数组，然后是有效类型 为该访问和后续访问修改的对象 不修改值是从中的对象的有效类型 该值被复制，如果它有一个。对于所有其他访问 没有声明类型的对象，对象的有效类型是 只是用于访问的左值的类型。

这里的“没有声明类型的对象”是malloc或类似分配的对象（或子对象）。它清楚地表明，此类对象可以在任何时候以任何类型写入，并且这会将有效类型更改为所需的类型。

Answer 4

首先，请务必使用-fno-strict-aliasing 或编译器上的任何等效项。否则，即使满足所有对齐方式，编译器也可能使用别名规则来重叠同一内存块的不同用途。

我怀疑这是否符合标准作者的意图，但考虑到优化器可能非常激进，以致安全地实现与类型无关的内存池的唯一方法是禁用基于类型的别名分析。该标准的作者希望避免将某些使用基于类型的别名的编译器标记为不兼容。此外，他们认为他们可以根据编译器编写者的判断来判断如何识别和处理可能出现别名的情况。他们确定了编译器编写者可能认为没有必要识别别名的情况（例如，在有符号和无符号类型之间），但希望编译器编写者能够做出合理的判断。我没有看到任何证据表明他们打算将他们的允许案例列表视为详尽无遗，即使在其他形式的别名也有用的平台上也是如此。

此外，无论人们多么谨慎地遵守标准，都不能保证编译器无论如何都会应用破坏性“优化”。至少从 gcc 6.2 开始，有别名错误会破坏将存储用作 X 类型的代码，将其写入 Y，将其读取为 Y，写入与 X 相同的值，并将存储读取为 X--behavior，即 100根据标准定义的百分比。

如果处理了别名（例如使用指示的标志），并且您知道系统的最坏情况对齐要求，那么为池定义存储很容易：

union
{
   char [POOL_BLOCK_SIZE] dat;
   TYPE_WITH_WORST_ALIGNMENT align;
} memory_pool[POOL_BLOCK_COUNT];

不幸的是，即使解决了所有平台相关的对齐问题，该标准也无法避免基于类型的别名问题。

Answer 5

回答 OP 的问题之一

如何在不调用未定义行为的情况下完成此操作（想要 malloc() 像这样的块）？

一种空间低效的方法。分配一个union 的类型。如果较小类型所需的尺寸不太大，则合理。

union common {
  struct foo f;
  void * ptr;
  char ch;
};

void *allocate3(struct foo **f, size_t m, void **ptr, size_t n, char **ch,
    size_t o) {
  size_t sum = m + n + o;
  union common *u = malloc(sizeof *u * sum);
  if (u) {
    *f = &u[0].f;
    *ptr = &u[m].ptr;
    *ch = &u[m + n].ch;
  }
  return u;
}

void sample() {
  struct foo *f;
  void *ptr;
  char *ch;
  size_t m, n, o;
  void *base = allocate3(&f, m, &ptr, n, &ch, o);
  if (base) {
    // use data
  }
  free(base);
}