【发布时间】:2014-07-19 05:22:57
【问题描述】:
我目前正在使用 gdb 来查看低级代码的效果。现在我正在做以下事情:
int* pointer = (int*)calloc(1, sizeof(int));
然而,当我在 gdb 中使用 info proc mappings 检查内存时,在我认为是 .text 部分之后看到以下内容(因为 Objfile 显示了我正在调试的二进制文件的名称):
...
Start Addr End Addr Size Offset Objfile
0x602000 0x623000 0x21000 0x0 [heap]
我所做的只是为单个 int 分配空间,为什么堆这么大?
最奇怪的是,即使我在做calloc(1000, sizeof(int)),堆的大小仍然保持不变。
PS:我在 x86_64 机器上运行 Ubuntu 14.04。我正在使用 g++ 编译源代码(是的,我知道我不应该在 C++ 中使用 calloc,这只是一个测试)。
【问题讨论】:
-
当您以后可能很想分配更多空间时,为什么系统要推测性地分配少量内存?
-
不仅可能需要更多空间,而且很可能您需要更多空间。
-
@user3688293:堆是一种类似于数组或链表的数据结构,并且和链表一样,它具有下一个元素指针等。这些必须与您的数据一起存储。使用像单个
int这样的小分配实际上是非常浪费的。 -
现在,浪费并不能解释为什么你的堆从 132 kB 开始。这与从操作系统请求内存的成本有关。您的 C 库分配器会立即从操作系统中获取大块,以避免经常支付该成本。
-
Ben 的描述对于大多数实现来说都是典型的。运行时可能实现一个sub-allocator,它通过系统调用获取一个相当大的最小堆块,并用它自己的子分配算法将其划分为更小的要求。大多数体面的运行时都以一种或另一种形式执行此操作,因为系统堆管理历来昂贵。
标签: c++ c gdb heap-memory