Build fluency in the vocabulary of free memory scattering into small, unusable gaps after many allocations and frees.
0 / 5 completed
1 / 5
At standup, a dev mentions that after many allocations and frees of different sizes, a heap ends up with enough total free memory to satisfy a new request, but no single contiguous block large enough, because the free memory is scattered in small, unusable gaps. What is this phenomenon called?
Memory fragmentation is exactly this: after many allocations and frees of varying sizes, a heap can end up with enough total free memory to satisfy a new request, but scattered across many small, non-contiguous gaps instead of one contiguous block large enough to actually fulfill it. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This scattered-into-small-gaps phenomenon is exactly why an allocation can fail with an out-of-memory error even when the total free memory reported would seem more than sufficient.
2 / 5
During a design review, the team picks a slab or arena allocator for a specific workload specifically because its uniform or bulk-freed allocation pattern avoids leaving behind the kind of scattered, unusable gaps a general-purpose allocator can accumulate. Which capability does this choice address?
Picking a slab or arena allocator here addresses reducing memory fragmentation, since a slab allocator's uniform slot sizes or an arena allocator's bulk-free pattern avoid leaving behind the small, scattered, differently-sized gaps that a general-purpose allocator handling arbitrarily sized allocations and frees tends to accumulate over time. The allocator choice having no effect at all on fragmentation would contradict exactly why these specialized allocators are chosen for workloads prone to this problem. This structured-allocation-pattern benefit is exactly why fragmentation-prone workloads often move away from a general-purpose allocator toward one of these more specialized designs.
3 / 5
In a code review, a dev notices a long-running service allocates and frees many differently sized objects through a general-purpose allocator over its lifetime, with no attention paid to how that pattern might accumulate scattered, unusable gaps in the heap over time. What does this represent?
This is a missed consideration of memory fragmentation, since a long-running service allocating and freeing many differently sized objects through a general-purpose allocator is exactly the pattern that tends to scatter free memory into small, non-contiguous gaps over time, eventually risking an allocation failure even when the total free memory would seem sufficient. A cache eviction policy is an unrelated concept about discarded cache entries. This ignore-the-long-term-fragmentation-risk pattern is exactly the kind of overlooked concern a reviewer flags for a service expected to run for a long time.
4 / 5
An incident report shows a long-running service eventually failed an allocation with an out-of-memory error despite reporting a healthy amount of total free memory, because years of varied allocations and frees through a general-purpose allocator had scattered that free memory into small, non-contiguous gaps. What practice would prevent this?
Adopting an allocation strategy better matched to the service's actual allocation pattern, such as a slab allocator for fixed-size objects or an arena allocator for same-lifetime batches, reduces the scattering of free memory into small, non-contiguous gaps that accumulated over the service's long lifetime, which is exactly the fix for the allocation failure described in this incident. Continuing to rely on the general-purpose allocator's varied pattern regardless of accumulating fragmentation is exactly what let the fragmentation build up over years of operation. This pattern-matched allocator choice is a standard fix once fragmentation, not raw memory shortage, is identified as the actual cause of an allocation failure.
5 / 5
During a PR review, a teammate asks why the team cares about memory fragmentation at all, given that the total amount of free memory reported by the system stays roughly the same before and after fragmentation sets in. What is the reasoning?
Fragmentation doesn't necessarily reduce the total amount of free memory the system reports, but it can scatter that free memory across many small, non-contiguous gaps, so a request for one larger contiguous block can still fail even though the sum of all those scattered gaps would easily cover it. This is exactly why a healthy-looking total free-memory figure can be misleading, and why fragmentation is tracked and addressed as its own concern separate from simply monitoring total free memory.