Doug Lea 分配器的奇怪 malloc 行为

Question

我有一个非常小的系统，只有 16kb 堆，没有 mmap，没有交换。我正在使用 Doug Lea 分配器的最新版本 2.8.5 ftp:/ /g.oswego.edu/pub/misc/malloc-2.8.5.c

更新我做了一个更小的测试用例，更容易理解并查看我的问题

如果我分配8kb，释放它，分配 12kb，它正在工作（i！= NULL），我可以分配 12 kb：

char *i;
dlstats();
i = dlmalloc(8192);
printf("DEBUG: %p\n", i);
dlstats();
dlfree(i);
dlstats();
i = dlmalloc(12288);
printf("DEBUG: %p\n", i);
dlstats();
dlfree(i);
dlstats();

显示：

heap 0xa00003f0 sbrk 0xa00003f0 arena 0 ordblks 0 usmblks 0 uordblks 0 fordblks 0 keepcost 0
DEBUG: 0xa00003f8
heap 0xa00003f0 sbrk 0xa0002440 arena 8272 ordblks 1 usmblks 8272 uordblks 8200 fordblks 72 keepcost 32
heap 0xa00003f0 sbrk 0xa0002440 arena 8272 ordblks 1 usmblks 8272 uordblks 0 fordblks 8272 keepcost 8232
DEBUG: 0xa00003f8
heap 0xa00003f0 sbrk 0xa0003460 arena 12400 ordblks 1 usmblks 12400 uordblks 12296 fordblks 104 keepcost 64
heap 0xa00003f0 sbrk 0xa0003460 arena 12400 ordblks 1 usmblks 12400 uordblks 0 fordblks 12400 keepcost 12360

如果我首先分配一个太大的缓冲区（30kb），然后我分配 8kb，释放它，分配 12kb，它是工作（i == NULL），我无法分配12 kb：

char *i;
dlstats();
i = dlmalloc(30000);
printf("DEBUG: %p\n", i);
dlstats();
i = dlmalloc(8192);
printf("DEBUG: %p\n", i);
dlstats();
dlfree(i);
dlstats();
i = dlmalloc(12288);
printf("DEBUG: %p\n", i);
dlstats();
dlfree(i);
dlstats();

显示：

heap 0xa00003f0 sbrk 0xa00003f0 arena 0 ordblks 0 usmblks 0 uordblks 0 fordblks 0 keepcost 0
DEBUG: 0x0
heap 0xa00003f0 sbrk 0xa00003f0 arena 0 ordblks 0 usmblks 0 uordblks 0 fordblks 0 keepcost 0
DEBUG: 0xa00003f8
heap 0xa00003f0 sbrk 0xa0002430 arena 8256 ordblks 1 usmblks 8256 uordblks 8200 fordblks 56 keepcost 16
heap 0xa00003f0 sbrk 0xa0002430 arena 8256 ordblks 1 usmblks 8256 uordblks 0 fordblks 8256 keepcost 8216
DEBUG: 0x0
heap 0xa00003f0 sbrk 0xa0002430 arena 8256 ordblks 1 usmblks 8256 uordblks 0 fordblks 8256 keepcost 8216
heap 0xa00003f0 sbrk 0xa0002430 arena 8256 ordblks 1 usmblks 8256 uordblks 0 fordblks 8256 keepcost 8216

在每一时刻，仅进行一次分配并在分配之前释放另一个块，因此内存永远不应该碎片化。

Answer 1

我从 Doug Lea 那里得到了答案：

如果尝试延长（或
初始化）连续的 sbrk 段
失败，sysalloc 将空间标记为
不连续，以避免连续
否则会再次失败
破坏从 MORECORE 到
MMAP 可用时。

这会导致后续段不
可合并。目前没有
方法来覆盖此行为。但你
应该能够解决这个问题
删除第 4113-4 行

  else
    disable_contiguous(m); /* Don't try contiguous path in the future */

以后我会考虑添加一个
过程中控制这个的方法
其他一些计划支持
页面保护

Answer 2

我认为这一段（来自维基百科，所以不能保证）解释了为什么你会看到这种行为：

dlmalloc 的空闲空间段合并算法相当弱，主要是因为空闲空间合并会因导致 TLB 缓存耗尽而变得非常慢。它每（默认情况下）4096 个 free() 操作被调用，它的工作原理是迭代先前从系统请求但系统未连续返回的每个段。它尝试识别不包含已分配块的大范围内存，并将其段分成两部分，并将空闲内存返回给系统。如果 dlmalloc 是 VM 系统的唯一用户，则该算法效果很好，但如果 dlmalloc 与另一个分配器同时使用，则 dlmalloc 的空闲空间合并器可能无法正确识别空闲内存释放的机会。

http://en.wikipedia.org/wiki/Malloc#dlmalloc_and_its_derivatives