How Memory Allocation Actually Works

When your program calls malloc(64), what actually happens? Most CS courses hand-wave past this. Let's not.

The request

Your program asks the operating system for 64 bytes. But the OS doesn't deal in bytes — it deals in pages, typically 4KB chunks. So even a tiny allocation triggers a conversation between your program, the C runtime's allocator, and the kernel's virtual memory system.

The allocator's job

The allocator maintains a pool of already-mapped memory. When you call malloc, it first checks if it can satisfy the request from memory it already has. Only if the pool is exhausted does it ask the kernel for more via sbrk() or mmap().

This is why allocation is usually fast — most mallocs never touch the kernel. They're just pointer arithmetic inside userspace data structures.

Fragmentation

After thousands of allocations and frees, your heap starts looking like Swiss cheese — small free blocks scattered between used blocks. This is external fragmentation, and it's the central problem of memory allocation.

I built MemViz to see this in action. Watching fragmentation develop in real time taught me more than any textbook diagram.