The history of Unix's confusing set of low-level ways to allocate memory (2018)

This brought back memories from college, when I tried to write my own C memory allocator. It was decidedly simple and extremely inefficient (pretty sure it used linked lists...), but after much hacking I did eventually get it to work with some small CLI programs using the LD_PRELOAD trick... but when I tried launching Gimp, the inefficiency quickly became apparent. I think eventually the splash screen did come up, but I never gave it enough time fully to start!<p>My implementation used brk()&#x2F;sbrk() exclusively, but I thought about re-implementing with mmap(). Hell, maybe I can try to write an allocator in Rust and expose a C-compatible interface.

This sounds so ancient, but I clearly remember seeing the sbrk() system call happening a lot when strace&#x27;ing processes on Linux, so it can&#x27;t be much more than 20 years ago, or maybe much less even. When did allocators on Linux stop doing that? glibc?<p>EDIT: Never mind, the article answers that eventually, it&#x27;s still used apparently: &quot;I know that GNU libc does use brk() based allocation for programs that only make small allocations, for example &#x2F;usr&#x2F;bin&#x2F;echo.&quot;

It&#x27;s worth noting that WebAssembly, at least for the moment, only supports a single brk&#x2F;sbrk-style growable heap -- allocators targeting the web can&#x27;t use any of the mmap tricks.

So much amusing past tense there, given that Linux has a sbrk() function and Glibc cheerfully uses it for small allocations in single-threaded programs. This stuff is today.

Tangentially, libraries for microcontrollers (e.g. nanolib) will typically use sbrk(). To port the library to a new architecture for the memory stuff you usually implement sbrk() yourself, and this will be sufficient for malloc and friends to compile

On the other hand, as far as I know, there was never the concept of a &quot;brk&quot; in the DOS&#x2F;Windows world; in DOS, by default programs got all memory (no virtual memory, all physical), and there was a set of malloc&#x2F;free&#x2F;realloc-ish functions for TSRs and other &quot;advanced&quot; techniques. DOS-based Windows memory allocation goes through DPMI which again provides similar functionality to malloc&#x2F;free&#x2F;realloc, as well as mmap. NT-based Windows is similar but without the DPMI.

Tangential question: Is anything considered state-of-the-art in terms of replacing POSIX?

I&#x27;m not sure what&#x27;s supposed to be confusing here but one thing I don&#x27;t know is why it was called the heap. Did they use heap data structures or something?

There is another way unix allocates memory, and that is with automatically growing regions that are used to allocate program stack.

This is pretty typical in nearly every modern operating system - the kernel hands out large chunks of memory and the user-mode side actually does the accounting to implement malloc&#x2F;free. Memory management in NT is also done in usermode (i.e. in-process)