240 likes | 833 Vues
This document discusses free-space management in memory allocation and deallocation processes within operating systems. It highlights the differences between fixed-sized and variable-sized memory units, focusing on issues like external fragmentation and the challenges of memory requests. Techniques such as splitting and coalescing are explored, alongside memory allocation policies like Best Fit, Worst Fit, and First Fit. The example code illustrates practical memory allocation behavior and the impact of fragmentation on system performance.
E N D
Free-Space Management Junghyeon Joo(jhjoo@theory.snu.ac.kr) School of Computer Science and Engineering Seoul National University
Free-Space Management • Given free space, memory allocation and deallocation are requested • OS allocates memory to a new process and deallocates memory from a terminated process • User program calls malloc() and free() • Fixed-sized memory unit • Easy to handle compared to variable-sized case • EX) paging • Variable-sized memory unit • EX) segmentation, malloc() / free()
Assumption void * malloc (size_t size) void free (void * ptr) • Interface for allocation / deallocation • Allocation • Take the number of requested bytes as parameter • Return the start address of allocated memory • Deallocation • Take a pointer as parameter ( No other information ) • No internal fragmentation • Only focus on external fragmentation • No relocation • No compaction of free space as cure for fragmentation
External Fragmentation used free free 0 10 20 30 Request for 15 bytes • The free space gets chopped into little pieces • Memory allocation request may fail, even though the total amount of free space exceeds the size of the request
External Fragmentation used free free 0 10 20 30 Request for 15 bytes • The free space gets chopped into little pieces • Memory allocation request may fail, even though the total amount of free space exceeds the size of the request A request for 15 bytes will fail,even though there are 20 bytesfree
Splitting used free free 0 10 20 30 head head NULL NULL addr:0 len:10 addr:0 len:10 addr:25 len:5 addr:20 len:10 Split used used free free 0 10 20 25 30 • Example Request for 5 bytes
Coalescing used free free 0 10 20 30 head head NULL addr:0 len:10 addr:0 len:10 addr:20 len:10 addr:10 len:10 free free free 0 10 20 30 addr:20 len:10 NULL • Example free(10)
Coalescing free free free 0 10 20 30 addr:20 len:10 NULL head head head addr:0 len:10 addr:0 len:10 addr:0 len:30 addr:20 len:10 addr:10 len:10 free 0 10 20 30 NULL • Merge neighboring free space Merge
Tracking The Size Of Allocated Regions typedef struct __header_t { int size; int magic; } header_t; void free(void * ptr) { header_t *hptr = (void *) ptr – sizeof(header_t); int BlockSizeToFree = hprt->size + sizeof(header_t); assert(hprt->magic == 1234567) … • Recall ‘free(void * ptr)’ doesn’t take a size parameter • Stored in extra header block • When user calls free() • The magic number is used for a sanity check
Tracking The Size Of Allocated Regions head size: 100 magic: 1234567 ptr 100B Memory Header size overhead also needs to be concerned in finding proper free space • Example
sbrk() System Call char * sbrk (int incr) Before the call of malloc() sbrk(0) : 0x6000 malloc(4) malloc(4) malloc(4) malloc(4) sbrk(0) : 0x8000 sbrk(0) : 0x8000 sbrk(0) : 0x8000 sbrk(0) : 0x8000 • sbrk() • It specifies for the OS to give incr more bytes to the heap • It returns a pointer to the end of the heap before sbrk() wascalled • Thus the call of sbrk(0) returns the current end of the heap • malloc() calls sbrk() internally to grow the heap • But not every time… Each time sbrk() is called it requests sufficient memory
Running Example on The Real OS [code] 1 main(){ 2int* buf, size, i = 1000; 3 for( size=4; size<20;size+=4{ 4 buf=(int*)malloc(size); 5 buf[0]=i++; 6printf(“Allocated %d bytes, buf : 0x%x, buf[0]:%d,buf[-1]:%d, buf[-2]:%d\n”,size, buf, buf[0], buf[-1], buf[-2]); 7 } [output] Allocated 4 bytes, buf : 0x8049780, buf[0]:1000,buf[-1]:17,buf[-2]:0 Allocated 8 bytes, buf : 0x8049780, buf[0]:1001,buf[-1]:17,buf[-2]:0 Allocated 12 bytes, buf : 0x8049780, buf[0]:1002,buf[-1]:17,buf[-2]:0 Allocated 16 bytes, buf : 0x8049780, buf[0]:1003,buf[-1]:25,buf[-2]:0 • Linux 2.2.10
Memory Allocation Policy • Best Fit • Allocate to the smallest possible free space • It tries to reduce wasted space, but produces lots of small chunks • A full search of free space is required • Worst Fit • Allocate to the largest possible free space • It tries to leave big chunks free • A full search is required like Best Fit • First Fit • Allocate to the first possible free space • Search cost is reduced • Variation : search from the last search position rather than the beginning (Next Fit)
Memory Allocation Policy A free list with three elements of sizes 10, 30 20 20 NULL 30 An allocation request of size 15 head head head head head head addr:0 len:10 addr:0 len:10 addr:0 len:10 addr:20 len:10 addr:20 len:10 addr:20 len:10 10 NULL 30 5 10 NULL 10 15 20 • Best Fit • Worst Fit & First Fit
Other Approache 32KB 16KB 16KB 8KB 8KB • Segregated List • For a particular application that has a few popular-sized request • Keep a separate list just to manage request for that size • Other requests are handled by general policy • Buddy Allocation • Improve coalescing performance • Ex) search for a 7KB block
Summary • Splitting & Coalescing • Header to store size of each allocated block • General Policy • Best Fit • Worst Fit • First Fit • Other Approache • Segregated List • Buddy Allocation