A general-purpose memory allocator turns large regions of process memory into smaller allocations requested and released in an unpredictable order.

Why allocation needs bookkeeping

A bump pointer can allocate quickly by advancing through unused memory, but it cannot reuse arbitrary freed blocks. A general allocator therefore tracks available blocks and their sizes.

Free lists, splitting and coalescing

Freed blocks can be organized in free lists or size classes. A large free block can be split to satisfy a smaller request; adjacent free blocks can be coalesced to recover a larger region.

Fragmentation

External fragmentation leaves enough total free memory but not in a suitably large contiguous block. Internal fragmentation wastes space inside allocated blocks because of alignment or size classes.

Concurrency

A single allocator lock can become a bottleneck. Per-thread caches, arenas and other partitioning techniques improve scalability but can increase memory use and implementation complexity.

Relationship with the operating system

An allocator normally obtains comparatively large virtual-memory regions from the operating system and serves many malloc-like requests from them. Individual allocations are usually user-space bookkeeping rather than one system call each.

Heap allocation is slower than stack-pointer adjustment because it solves a much less constrained lifetime and reuse problem.