1. Chapter 17 Free-Space Management
Chien-Chung Shen
CIS/UD

2. Problem
The problem of managing free space exists in both malloc library and OS itself
Easy for fixed-sized units (e.g., paging) vs. hard for variable-sized units
The problem: external fragmentation
free space gets chopped into little pieces of different sizes and is thus fragmented
subsequent requests (e.g., 15) may fail because there is no single contiguous space that can satisfy the request, even though the total amount of free space exceeds the size of the request
minimize fragmentation

3. User-level Memory Allocation
User-level memory allocation library with malloc() and free()
user, when freeing the space, does not inform the library of its size; thus, the library must be able to figure out how big a chunk of memory is when handed just a pointer to it
Heap
Free list
data structure used to manage free space in heap
contains references to all of the free chunks of space in the managed region of memory

4. Low-level Mechanisms Splitting and coalescing
Tracking the size of allocated regions
Embedding free list inside the free space to keep track of what is free and what isn’t
Growing the heap (via system call sbrk)

5. Splitting and Coalescing
A (conceptual) free list contains a set of elements that describe the free space still remaining in the heap
Request 1 byte
splitting
Free 10 bytes
coalescing
if the newly-freed space sits right next to one (or two, as in this example) existing free chunks, merge them into a single larger free chunk

6. Tracking Size of Allocated Regions
How does free(void *ptr) know how how many bytes to free?
typedef struct __header_t {
int size;
int magic; // integrity check
} header_t;
void free(void *ptr) { header_t *hptr =
(void *)ptr - sizeof(header_t);
... }
hptr->size + sizeof(header_t)
ptr = malloc(20);
when a user requests N bytes of memory, the library searches for a free chunk of size N plus the size of the header

7. Embedding A Free List (1)
Build free list inside free space itself
typedef struct __node_t {
int size;
struct __node_t *next;
} node_t;
// mmap() initializse 4KB of heap (free) space
node_t *head = mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_ANON|MAP_PRIVATE, -1, 0);
head->size = 4096 – sizeof(node_t);
head->next = NULL;
Assuming 4096 bytes of free space

8. Embedding A Free List (2)
Request 100 bytes
find a chunk large enough
split the chunk
16 * 1024 = 16384
= 16492
(3980 = 4096 – 8 – 108)

9. Embedding A Free List (3)
3 allocated regions
free(sptr)
sptr is 16500
add free chunk back to free list by inserting at the head
16384
(108 * 3)
= 16708

10. Embedding A Free List (4)
Free two chunks
How many chunks? 4
non-coalesced
How can you do better?
go through the list and coalesce (merge) neighboring chunks

11. Growing Heap
When running out of heap, memory allocation library makes system call (e.g., sbrk()) to grow the heap
To serve sbrk(), OS
finds free physical pages
maps them into the address space of the requesting process
returns the value of the end of the new heap

12. Allocation Strategies
Best fit - search through free list and return the smallest block of free memory that is bigger than the requested size
Worst fit – opposite of best fit
First fit – find the first block that is big enough and return the requested amount
Next fit – not begin the first-fit search at the beginning of the list
Their pros and cons

13. Buddy System
Comprised of fixed and dynamic partitioning schemes
Space available for allocation is treated as a single block
Memory blocks are available of size 2K words, L ≤ K ≤ U, where
2L = smallest size block that is allocated
2U = largest size block that is allocated; generally 2U is the size of the entire memory available for allocation
Both fixed and dynamic partitioning schemes have drawbacks. A fixed partitioning scheme limits the number of active processes and may use space inefficiently if there is a poor match between available partition sizes and process sizes. A dynamic partitioning scheme is more complex to maintain and includes the overhead of compaction. An interesting compromise is the buddy system ([KNUT97], [PETE77]).
Memory blocks are available of size 2K words, L ≤ K ≤ U, where
2L = smallest size block that is allocated
2U = largest size block that is allocated; generally 2U is the size of the entire memory available for allocation
To begin, the entire space available for allocation is treated as a single block of size 2U . If a request of size s such that 2U –1 < s 2U is made, then the entire block is allocated. Otherwise, the block is split into two equal buddies of size 2U –1 . If 2U –2 < s 2U –1 , then the request is allocated to one of the two buddies. Otherwise, one of the buddies is split in half again. This process continues until the smallest block greater than or equal to s is generated and allocated to the request. At any time, the buddy system maintains a list of holes (unallocated blocks) of each size 2 i . A hole may be removed from the ( i + 1) list by splitting it in half to create two buddies of size 2 i in the i list. Whenever a pair of buddies on the i list both become unallocated, they are removed from that list and coalesced into a single block on the ( i + 1) list.

14. Buddy Allocation
search for free space recursively divides free space by two until a block that is big enough to accommodate the request is found
(William Stallings: OS)

15. Buddy Allocation
(William Stallings: OS)

16. Segregated Lists
If a particular application has one (or a few) popular-sized request that it makes, keep a separate list just to manage objects of that size; all other requests are forwarded to a more general memory allocator
benefit: fragmentation is much less of a concern; allocation and free requests can be served quite quickly
Slab allocator