Memory Management Overview

Outline Introduction to memory management Managing memory with bitmaps and lists Simple memory management and fragmentation

Introduction to Memory Management OS needs to manage physical memory Allocate memory for programs and for itself Requirements Isolation: programs should be protected from other programs Abstraction: programs have the illusion that they have as much memory as their virtual address space Sharing: programs should be able to share memory with other programs for communication Goals Low memory overhead: programs should be able to use as much as memory as possible Low Performance overhead: CPU should be spend as much time executing programs as possible

Programs and Memory Addresses When a program is written, it uses variable names When a program runs, it accesses physical memory addresses Setting up mapping from program variables to memory addresses requires compiler, linker, OS and h/w support

Compiler, Linker, OS and H/W Converts program source file to object file Generates relocatable virtual memory addresses Linker Links together multiple object files to single program on disk Generates absolute virtual memory addresses OS Loads program and dynamic libraries into physical memory Links program code with dynamic library code Sets up virtual memory hardware H/W Translates virtual memory address to physical address absolute addresses refer to either constant address values (e.g., 0xffff5454), or address values relative to PC (relative addressing, e.g., +0x24). relocatable addresses are generated with respect to the start of section, e.g., start of an object file. When the linker links the object files together, it generates absolute addresses from the relocatable addresses.

Generating Memory Addresses On disk Virtual memory Physical memory 1500 2000 2020 2025 2030 2060 ... pr: main: call +35 call -530 f: 7500 8000 8020 8025 8030 8060 ... pr: main: call +35 call -530 f: main: f(); pr(); main: call ?? 20 25 60 main: call +35 call ?? f: ... Note that the calls are relative to the next PC, e.g., call +35 == call (25+35) == call 60 == call f in the executable. similarly, call -530 == call (2030-530) == call 1500 == call pr. when OS loads program, normally, most addresses are relative (e.g., +35), so those don’t need to be patched (changed). However, addresses for calls to dynamically loaded libraries (e.g., call to pr) need to be patched (e.g., -530). Show demo of address space using memory/program.c on ug machine nm –o program.o (doesn’t have addresses for lib_f, printf, has address for main, but it is 0) nm –o lib.o (doesn’t have address for malloc, has address for lib_f, but it is 0) nm –o program | grep main (absolute virtual memory address) nm –o program | grep lib_f (absolute virtual memory address) nm –o program | grep printf (doesn’t have address) ldd program nm –D /lib/x86_64-linux-gnu/libc.so.6 | grep “ printf” (has address for printf) readelf –S program | less Look for .text, and .data, and their Address and Size fields. Use gdb() to show the address of main(), f() and the global ‘a’ variable. these addresses should lie within those ranges. Then run the program under gdb(), and show that the OS loader loads the program at virtual addresses that are different from the addresses in the executable. f: ... f: ... MMU base: 6000 Compilation Linker OS Loader H/W

Managing Memory Boot loader, loads OS code and data in low memory After that, OS needs to track the usage of the rest of the physical memory OS tracks what memory is allocated (used) or free (unused), similar to heap addr = kmalloc(size) Allocate contiguous memory of a given size Address of allocated memory is returned kfree(addr) Program frees memory previously allocated at address addr Two common techniques for managing memory Bitmaps, linked lists

Managing Memory With Bitmaps A Bitmap is a long bit string One bit for every chunk of memory 1 = in use 0 = free Size of chunk determines size of bitmap Chunk size = 32 bits Overhead for bitmap = 1/(32 + 1) = 3% Chunk size = 4 KB Overhead for bitmap = 1/(4 * 1024 * 8 + 1) = 1 / 32769 Larger chunk size Lower overhead Wastes more space (on average, half chunk size), called internal fragmentation

Bitmap Operations mem = allocate(K) free(mem, K) Search bitmap for K consecutive 0 bits Set the K bits to 1 Cost: linear search free(mem, K) Determine starting bit in bitmap based on memory address Set next K bits to 0

Managing Memory With Linked Lists Keep a list of elements, one for each allocated or free region of memory Each element has the following information Allocated or free region (hole) Starting address of memory Length of region Pointer to next element of list A A A A A

Managing Memory With Linked Lists mem = allocate(K) Search linked list for a hole (free region) with size >= K When size > K, break hole into allocated region, smaller hole free(mem, K) Determine region based on memory address Convert allocated region into hole Merge with adjacent hole to avoid small holes

Searching Linked Lists Could use a separate allocated and free list First Fit: Start searching at the beginning of the list Best Fit: Find the smallest hole that will work Tends to create lots of little holes Quick Fit: Keep separate lists for common sizes Efficient but more complicated implementation

Simple Memory Management A basic memory management system assigns each program a contiguous region in physical memory Region size depends on program size OS occupies one region Problems Internal fragmentation: program doesn’t use entire region External fragmentation: a large enough region cannot be allocated to the program, even if enough memory is available Can use compaction, i.e., move processes periodically to collect all free space into one hole, expensive Allocating additional memory is expensive: can’t grow region, requires copying entire program into another larger region Both types of fragmentation result in wasted, inefficient use of memory and storage

Summary OS needs to allocate physical memory to programs (and to itself) with low overhead Bitmaps, linked lists are two methods for managing memory Programs uses similar techniques for managing their heap A simple memory management scheme allocates contiguous physical memory to programs Makes it hard to grow programs Wastes memory due to internal and external fragmentation

Think Time What is the difference between a virtual and a physical memory address? Why is hardware support required for address translation? How does the OS manage memory using bitmaps? using lists? Under which conditions is each approach preferable? What is internal and external fragmentation? - difference between virtual and physical virtual: address seen by CPU, physical: address seen by memory - h/w support for address translation Would be too slow in software Under which condition is bitmap/linked list preferable Read book Internal frag: allocated region of memory is not fully used External frag: holes between allocated regions are fragmented, so large memory allocations are not possible, without compacting allocated regions