The Heap and Dynamic Memory

Unlike stack memory, which is automatically reclaimed when a function returns, and static memory declared in .data/.bss, which exists for the program's entire lifetime, heap memory is requested and released explicitly at runtime, giving the program control over allocation sizes and lifetimes that aren't known until the program is actually running. On Linux, the two lowest-level mechanisms to grow the heap are the brk/sbrk syscalls, which extend a single contiguous program break, and mmap, which asks the kernel for an entirely separate mapped region, typically used for larger allocations.

The brk syscall sets the program break — the end of the process's data segment — to an absolute address, while sbrk (a libc wrapper, not a syscall itself) adjusts it by a relative increment and returns the previous break address, which is exactly where the newly available memory begins. Because brk only ever moves one boundary up or down, it is inherently a single contiguous region and cannot easily return memory to the OS except by shrinking from the very top, which is why general-purpose allocators built on brk must manage free lists internally rather than repeatedly calling brk for every small allocation.

A minimal heap allocator built on top of brk needs its own bookkeeping: each allocated block is typically prefixed with a small header storing at least its size (and often a free/used flag and pointers to neighboring blocks), so that a corresponding 'free' operation knows how many bytes to reclaim and can potentially merge adjacent free blocks to fight fragmentation. Since assembly has no automatic garbage collector, forgetting to free a block — or losing the only pointer to it by overwriting the register/variable holding its address — permanently leaks that memory for the remainder of the process's life.