Memory Management 5A. Memory Management and Address Spaces 5B. - PDF document

4/10/2016 Memory Management 5A. Memory Management and Address Spaces 5B. Allocation Algorithms Operating Systems Principles 5C. Advanced Allocation Techniques Memory Management 5D. Segment Relocation 5E. Garbage Collection Mark Kampe 5F. Common Errors and Diagnostic Free Lists (markk@cs.ucla.edu) Memory management 2 Memory Management Memory Management Goals 1. allocate/assign physical memory to processes 1. transparency – explicit requests: malloc (sbrk) – process sees only its own virtual address space – implicit: program loading, stack extension – process is unaware memory is being shared 2. manage the virtual address space 2. efficiency – instantiate virtual address space on context switch – high effective memory utilization – extend or reduce it on demand – low run-time cost for allocation/relocation 3. manage migration to/from secondary storage 3. protection and isolation – optimize use of main storage – private data will not be corrupted – minimize overhead (waste, migrations) – private data cannot be seen by other processes Memory management 3 Memory management 4 Linux process virtual address space Physical Memory Allocation a process's virtual address space is made up of all of the memory locations that the process can process 1 shared lib X data and stack address, and looks as if the process had all of OS kernel shared code process 3 memory for its own private use segment A data and stack process 2 data and stack code segment data segment stack segment hole shared code segment B 0x00000000 0xFFFFFFFF Physical memory is divided between the OS kernel, Code segment loaded near beginning of address space process private data, and shared code segments. Data segment starts at page boundary after code segment Stack segment starts at high end of address space Memory management 5 Memory management 6 1

4/10/2016 (code segments) Linux Process – virtual address space • program code – allocated when program loaded 0x00000000 0x0100000 0x0110000 – initialized with contents of load module shared code private data DLL 1 DLL 2 • shared and Dynamically Loadable Libraries – mapped in at exec time or when needed DLL 3 private stack • all are read-only and fixed size 0x0120000 0xFFFFFFFF – somehow shared by multiple processes All of these segments appear to be present in memory – shared code must be read only whenever the process runs. Memory management 7 Memory management 8 (implementing: code segments) (data/stack segments) • program loader • they are process-private, read/write – ask for memory (size and virtual location) • initialized data – copy code from load module into memory – allocated when program loaded • run-time loader – initialized from load module – request DLL be mapped (location and size) • data segment expansion/contraction – edit PLT pointers from program to DLL – requested via system calls (e.g. sbrk) • memory manager – only added/truncated part is affected – allocates memory, maps into process • process stack – allocated and grown automatically on demand Memory management 9 Memory management 10 (implementing: data/stack) Fixed Partition Memory Allocation • pre-allocate partitions for n processes • program loader – reserving space for largest possible process – ask for memory (location and size) • very easy to implement – copy data from load module into memory – common in old batch processing systems – zero the uninitialized data • well suited to well-known job mix • memory manager – must reconfigure system for larger – invoked for allocations and stack extensions processes • likely to use memory inefficiently – allocates and deallocates memory – large internal fragmentation losses – adjusts process address space accordingly – swapping results in convoys on partitions Memory management 11 Memory management 12 2

4/10/2016 (Internal Fragmentation) Internal Fragmentation partn #1 partn #2 partn #3 • wasted space in fixed sized blocks 8MB 4MB 4MB • caused by a mis-match between waste 2MB – the chosen sizes of a fixed-sized blocks – the actual sizes that programs request • average waste: 50% of each block process waste 1MB A waste 2MB • overall waste reduced by multiple sizes (6 MB) process process B – suppose blocks come in sizes S1 and S2 C (3 MB) (2 MB) – average waste = ((S1/2) + (S2 - S1)/2)/2 Total waste = 2MB + 1MB + 2MB = 5/16MB = 31% Memory management 13 Memory management 14 Stack vs Heap Allocation Variable Partition Allocation • stack allocation • start with one large "heap" of memory – compiler manages space (locals, call info) • when a process requests more memory – data is valid until stack frame is popped – find a large enough chunk of memory – OS automatically extends stack segment – carve off a piece of the requested size • heap allocation – put the remainder back on the free list – explicitly allocated by application (malloc/new) • when a process frees memory – data is valid until free/delete (or G.C.) – put it back on the free list – heap space managed by user-mode library • eliminates internal fragmentation losses – data segment size adjusted by system call Memory management 15 Memory management 16 (Free lists: keeping track of it all) Variable Partition Free List • fixed sized blocks are easy to track F N L head R E E E X N E T – a bit map indicating which blocks are free U N L • variable chunks require more information S E E E X N D T List might – a linked list of descriptors, one per chunk contain all F N L R E E E X memory N E T – each lists size of chunk, whether it is free fragments U N L – each has pointer to next chunk on list S E E …or only E X N D T B 1 fragments – descriptors often at front of each chunk F N that are free. L R E E E X N • allocated memory may have descriptors too E T … Memory management 17 Memory management 18 3

4/10/2016 Free Chunk Carving External Fragmentation U N L S E E P F E X N P A P A D T 1. find large enough free chunk P D P D U P B S 2. reduce len to requested size E D F N F N L L R E R E E E P C P C P C E X E X N N 3. new header for residual chunk E T E T 4. insert new chunk into list P E P E U N L S E E E X N 5. mark carved piece as in use D T … … Memory management 19 Memory management 20 (External/Global Fragmentation) Which chunk: best fit • each allocation creates left-overs • search for the "best fit" chunk – over time they become smaller and smaller – smallest size greater/equal to requested size • the small left-over fragments are useless • advantages: – they are too small to satisfy any request – might find a perfect fit – a second form of fragmentation waste • disadvantages: • solutions: – have to search entire list every time – try not to create tiny fragments – quickly creates very small fragments – try to recombine fragments into big chunks Memory management 21 Memory management 22 Which chunk: worst fit Which chunk: first fit • search for the "worst fit" chunk • take first chunk that is big enough – largest size greater/equal to requested size • advantages: • advantages: – very short searches – tends to create very large fragments – creates random sized fragments … for a while at least • disadvantages: • disadvantages: – the first chunks quickly fragment – still have to search entire list every time – searches become longer – ultimately it fragments as badly as best fit Memory management 23 Memory management 24 4