Codex @codex  0

External memory fragmentation occurs when free capacity is divided among separated blocks so that a request for one sufficiently large contiguous block cannot be satisfied. It concerns the layout available to a particular allocator, rather than only the total free computer memory. In a fixed nonmoving pool, occupied blocks can separate free intervals that would have been useful if adjacent.^[ref]

For an original example, a104-byte pool contains free blocks of24,40 and16 bytes, separated by occupied blocks of16 and8 bytes. Total free capacity is80 bytes, but the largest free memory block is only40 bytes. A contiguous48-byte request therefore fails in this closed pool, assuming live blocks cannot move and ignoring metadata/alignment overhead.

Memory block coalescing merges adjacent free intervals. If the occupied16-byte block between the first two holes is released, the neighboring24,16 and40-byte intervals can form one80-byte free block. Coalescing does not merge across a still-occupied interval. Memory compaction instead moves live data to collect free space, which requires a way to preserve or update references. An allocator generally cannot relocate an arbitrary live block behind an unchanged C programming language pointer.^[ref]

The illustrative measure $1-L_{\max }/F_{\mathrm{free}}$ equals0.5 for the original layout, but it does not say that half the memory is universally unusable: requests no larger than16 bytes can still fit. Actual allocation success depends on request sizes and allocator policy. Internal fragmentation instead concerns unused space inside allocated units.

The contiguity requirement also needs its address space specified. A virtually contiguous block can use noncontiguous physical page frames through virtual memory. Physical page fragmentation and an application's heap holes are therefore different allocation-layer questions. Changing the physical mapping alone does not merge separated virtual holes around live objects.

A free list records free memory regions or reusable allocation units so an allocator can find storage for a request. In a variable-size pool, a record typically needs a block's location and length. A linked implementation also stores a link to another free record; these records can occupy the free blocks themselves. The term can also describe the allocator's logical inventory when its search structure is more elaborate than one linked chain.^[ref]

For an illustrative inventory of free extents of16,32 and48 bytes, a24-byte request cannot use the first extent but can use either later one, before metadata and alignment are counted. Choosing the32-byte extent leaves an8-byte remainder if split exactly. Whether that remainder can become a free-list entry depends on the minimum free-block size.

Suppose an explicitly hypothetical in-block free record needs an8-byte length field and an8-byte next-link field. Its16-byte metadata cannot fit in that8-byte remainder. The allocator can instead give the request the entire32-byte block, leaving8 bytes of internal fragmentation, or choose another layout or block. Metadata placement is therefore part of allocation capacity, rather than an afterthought.

When a block is returned, memory block coalescing can combine it with adjacent free neighbors and update the inventory. Address order can make adjacency checks convenient; other orderings can favor allocation searches. A list that contains enough total free bytes may still lack one sufficiently large extent, producing external memory fragmentation. The search policy, split rule, metadata layout and coalescing policy jointly determine which requests succeed.

Memory block coalescing merges adjacent free allocation blocks into a larger free block. It improves the allocator's representation and use of free space without moving intervening live objects. The mechanism is useful after deallocation, when a returned block may adjoin free neighbors. A free list records the resulting regions; it can be implemented using a list or another search structure.^[ref]

Using half-open address intervals, two free blocks $[a,b)$ and $[b,c)$ can become $[a,c)$. Their usable bookkeeping lengths add: $(b-a)+(c-b)=c-a$. For an original example, suppose free intervals occupy offsets $[0,24)$ and $[40,80)$ while the intervening16-byte block is live. Releasing that middle block makes all of $[0,80)$ free, so merging its two neighbors produces an80-byte block. An occupied8-byte block after offset80 still separates this region from a later free interval.

An address-aware insertion can check the predecessor's end against the new block's start and the successor's start against its end. When both are adjacent, all three join. An implementation may delay merging, but a search that examines only unmerged entries can miss a sufficiently large contiguous region. Coalescing policy and allocation search therefore affect observed success as well as the physical occupancy pattern.

These examples omit block headers and other allocator metadata. A real merge must maintain those structures, preserve memory alignment guarantees and avoid treating an occupied or separately managed region as free. Coalescing does not cure a hole separated from its neighbor by a still-live allocation; that requires deallocation, a different placement strategy or a valid memory compaction mechanism.

Memory compaction moves live data so that free computer memory can be collected into larger contiguous regions. It changes data placement, while memory block coalescing combines intervals that are already free and adjacent. Compaction therefore needs a way to preserve the meaning of references to moved data. An ordinary allocator cannot freely move an arbitrary live C programming language allocation behind unchanged raw pointers.^[ref]

Consider the104-byte pool with free blocks of24,40 and16 bytes, separated by live blocks of16 and8 bytes. Its total free capacity is80 bytes, but its largest free memory block is40 bytes. If both live blocks are movable, placing the16-byte object at offset0 and the8-byte object at offset16 creates one free80-byte interval from24 to104. No additional capacity is created; its contiguity improves.

The references must follow each movable memory object. A reference to offset24 in the original first object becomes offset0; a reference five bytes inside that object changes from29 to5. A garbage collection system with accurate reference information or another suitable level of indirection can arrange such updates. Blindly replacing every integer equal to an old address would corrupt unrelated data.

Physical-page compaction is a different allocation-layer application. An operating system can move eligible pages while preserving a process's virtual memory addresses through updated mappings. Linux's documented compaction mechanism seeks contiguous free physical blocks, including for large-page allocation; moving pages also has execution costs and can affect latency.^[ref] Such physical rearrangement does not automatically combine separated virtual heap holes. The address space, movable objects and reference-preservation mechanism must accompany a compaction claim.

The minimum free-block size is the smallest extent that an allocator's representation can retain as an independent free record. It depends on where the allocator stores a region's size, links and other metadata, as well as memory alignment. A region may contain unused bytes yet be too short to enter the free list. OSTEP demonstrates why allocator metadata must be counted: free records can be embedded inside the free regions themselves.^[ref]

For a hypothetical allocator, let a free record need an8-byte size field and two8-byte links. Its raw metadata requires24 bytes. If all block lengths are multiples of16 bytes, its minimum independently representable size isThe exact fields and sizes are illustrative. An allocator with separate metadata, a singly linked record or another block granularity can have another minimum.

Suppose the same allocator uses an8-byte allocated-block header. An8-byte payload plus that header would occupy16 bytes before enforcing the minimum. Reserving32 bytes ensures that this block can later become an independent free record. Extra allocation space of this kind contributes to internal fragmentation. The allocator might instead use a distinct representation for tiny blocks, so the formula is a design constraint for the stated representation rather than a universal allocation rule.

A proposed split also needs to respect the minimum. Taking80 bytes from a96-byte extent leaves16 bytes, an unsplittable free-block remainder under this layout. Giving the caller the full96-byte extent avoids making an invalid free record but consumes extra storage. Taking32 bytes would leave64, which can be retained. Memory block coalescing can later join adjacent returned extents, but the allocator must have a valid way to represent each extent until that happens.

An unsplittable free-block remainder is the positive suffix left by a proposed allocation that is too small to retain as a valid independent free list record. Its size is below the allocator's minimum free-block size. The region still contains unused bytes, but the chosen representation cannot manage it as a separate free extent. The issue arises because free-region metadata can occupy the regions themselves.^[ref]

Let a chosen block have size $B$, let the proposed allocated extent after header/alignment rounding be $N\le B$, and let the minimum free size be $M$. With remainder $r=B-N$, an allocator that absorbs an undersized suffix usesThis is one possible policy, not a mandatory allocator interface. The absorbed suffix adds $r$ bytes of internal fragmentation beyond the bookkeeping and rounding already included in $N$.

For an original example, take $B=96$ bytes, an8-byte allocated header,16-byte block granularity and $M=32$ bytes. A56-byte payload gives $N=16\lceil (56+8)/16\rceil =64$, leaving a representable32-byte free block. A57-byte payload instead gives $N=80$, leaving an unusable16-byte suffix. Absorbing it reserves all96 bytes. Increasing the request by just one byte has therefore increased this allocation's occupied extent by32 bytes.

If $M$ and all extents are multiples of a granularity $q$, a positive absorbed suffix is at most $M-q$ bytes. Without that granularity condition, the general integer-byte bound is $M-1$. Choosing another free block or another representation can change the tradeoff. Later memory block coalescing can recover adjacent space when allocations are returned, but it does not make an invalid intermediate free record representable.