Chapter 17 Free-Space Management Chien-Chung Shen CIS/UD cshen@udel.edu

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

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

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)

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

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

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

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

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 16384 + (108 * 3) = 16708

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

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

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

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.

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)

Buddy Allocation (William Stallings: OS)

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