malloc and linux memory layout

[Rich Felker <dalias@aerifal.cx>]

Since Luka has had a number of questions about when/why malloc could
fail, heap/brk/mmap allocation, etc. I thought I'd post a quick
description of the virtual address space is managed on Linux:

Each process has its own 32- or 64-bit virtual address space.
Initially, from bottom to top, it looks something like:

[low unmappable pages]
[main program text (code) segment]
[main program data segment]
[brk segment (heap)]
[....lots of open virtual address space...]
[mmap zone]
[main thread stack]
[reserved for kernelspace use]

(Note that there will be small randomized amounts of empty/unused
address space between these regions if ALSR is enabled.)x

The brk segment starts just above the program's static data and grows
upward into the big open space. The mmap zone (where mmaps are put by
default) starts just below the stack limit and continues downward as
more mappings are made. Previously-mapped ranges here are available
for reuse after they're unmapped; that's managed by the kernel. The
brk is not allowed to run into any other mapping when it grows upward,
so if there's a mapping right above the brk segment, attempts to grow
it will always fail.

Shared libraries are mapped in the mmap zone just like another other
mmap.

Typically malloc implementations will use a mix of brk and mmap to
satisfy malloc requests, using individual mmaps for large allocations
(letting the kernel take care of it and making it easy to free the
whole thing back to the system) and carving up the brk segment (and
possibly additional mmapped regions) to handle small allocations (this
avoids the overhead of syscalls and page alignment for small
allocations). musl only uses brk for small allocations, but glibc's
ptmalloc and others are happy to use mmap to make a new "heap region"
if the brk can't grow. The difference will generally only be seen if
virtual address space has already been exhausted.

Hope this helps..

Rich