4 ms·
No, it is not wasted. The "holes" come with exact allocation. Making malloc block granularity bigger reduces memory internal fragmentation.
by faragon 12y ago
No, it is not wasted. The "holes" come with exact allocation. Making malloc block granularity bigger reduces memory internal fragmentation.
- haberman 12y agoLeaving holes is not free. There is an inherent tradeoff. That is all I am saying.
- kllrnohj 12y agoThe only cost is virtual address space fragmentation. Which, if you're 64-bit, is pretty much a non-existent problem as the address space is so absurdly larger than the amount of memory you have. Meaning the holes are entirely free. On 32-bit systems that fragmentation could potentially be a problem, but it's unlikely. The problem would come up if you did something like allocate 1GB worth of small allocations then suddenly tried to allocate a single 1GB allocation. In practice this tends to not really happen, either, so the holes remain free. Note that there is no scenario in which the holes cost actual RAM usage. It's purely the usage of the virtual address space, no machine resources are ever consumed by the holes.
- haberman 12y agoIt's not as simple as that, because pages are more than one byte long. If pages were one byte long, what you say would be (mostly) true. For every allocation, you would just map in some memory at some random place in the address space, and you would map in precisely as many bytes as were requested. You would literally waste no memory, and your reallocs would never need to move memory. Life would be bliss. But pages are not one byte long. They are usually something like 4k. So if you fulfill a 1-byte malloc() with a 4k page (to leave room for realloc()), you are wasting nearly 4k bytes of real physical memory. Also: mmap() system calls have CPU overhead, and I highly suspect that two non-contiguous mapped pages create more kernel overhead than two contiguous mapped pages. Holes are not free.