5 ms·
Umm.. that's not really true. Most userspace memory allocators are based on mmap(). Using sbrk() is legacy. The slab allocator (Bonwick, 1994) is the dominant
by rmind 7y ago
Umm.. that's not really true.
Most userspace memory allocators are based on mmap(). Using sbrk() is legacy. The slab allocator (Bonwick, 1994) is the dominant algorithm (both in userspace and the UNIX-like kernels), although there are various flavours and somewhat different implementations of it. Since it uses fixed-sized allocations under the hood, they are nicely packed in pages. Those pages can be released with munmap() once there are no used blocks. Sure, depending on the application and workload, allocations can be become quite distributed amongst the pages over the time, but that is a separate problem.
Also, as another comment states: madvise() is also an option, but it doesn't reclaim the virtual address space. On 32-bit systems VA space exhaustion can be a problem, especially with "modern" applications.
- rsecora 7y agoAnswers like this is the reason I came back to HN. Facts and to the point.
- wahern 7y agoBoth glibc and musl libc still uses brk for most allocations. You can see it when strace'ing simple programs. After the linker--which uses mmap for some allocations as it can't use malloc--has finished you'll see brk calls to satisfy application allocations. Also you can verify in the code, e.g. https://git.musl-libc.org/cgit/musl/tree/src/malloc/expand_heap.c?id=55a1c9c8#n56 https://git.musl-libc.org/cgit/musl/tree/src/malloc/expand_h... I believe OpenBSD's malloc only uses mmap and also aggressively munmap's memory--to better catch application bugs and to keep addresses randomized.