Operating Systems CMPSCI 377 Lecture 11 Memory Management

Operating Systems CMPSCI 377 Lecture 11: Memory Management Emery Berger University of Massachusetts, Amherst UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science

Course Outline n n n Processes & Threads CPU Scheduling Synchronization & Deadlock Memory Management File Systems & I/O Distributed Systems UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 2

Today: Memory Management n n n Terminology Addresses Uniprogramming Multiprogramming Relocation Allocation n n Policies Fragmentation Compaction Swapping UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 3

Memory Management n n n Where in memory is executing process? How do we allow multiple processes to share main memory? What’s an address and how is one interpreted? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 4

Background: Computer Architecture n n n Program executable on disk OS loads program into memory CPU fetches instructions & data from memory while executing program UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 5

Memory Management: Terminology n n n Segment: chunk of memory assigned to process Physical address: real address in memory Virtual address: address relative to start of process’s address space UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 6

Where Do Addresses Come From? Instruction & data addresses n Compile-time: n n Load-time: n n Exact physical location in memory starting from fixed position k OS determines process’s starting position, fixes up addresses Execution time: n OS can place address anywhere in physical memory UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 7

Uniprogramming Only one program at a time ) simplifies memory management n n OS gets fixed region of memory (e. g. , highest) One process at a time n n n Load at address 0 Executes in contiguous memory Compiler generates physical addresses n n Max address = memory size – OS size OS protected from process by checking addresses UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 8

Example: Uniprogramming n Simple – but no overlap of I/O, computation UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 9

Multiprogramming Requirements n Transparency n n n Safety n n n No process aware memory is shared Process has no constraints on physical memory Processes cannot corrupt each other Or the OS Efficiency n Performance not degraded due to sharing UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 10

Relocation n n Put OS in high memory Process starts at 0 n n n Max addr = memory size – OS size Load process by allocating contiguous segment for process Smallest addr = base, largest = limit UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 11

Static Relocation n n At load time, OS adjusts addresses in process to reflect position in memory OS cannot move process after relocation UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 12

Dynamic Relocation n n Hardware adds relocation register (base) to virtual address to get physical address Hardware compares address with limit register (addr must be less than base) n Test fails ) trap UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 13

Relocation, Pros & Cons n Advantages n OS can easily move process during execution n OS can allow process to grow over time n Simple, fast hardware n n Two special registers, add, & compare Disadvantages n Slows everything (add on every reference) n Can’t share memory between processes n n n Process limited to physical memory size Degree of multiprogramming limited n n “Text” section All memory of active processes must fit in memory Complicates memory management UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 14

Relocation, Properties n Transparency n n Safety n n Processes largely unaware of sharing Each memory reference checked Efficiency n n Memory checks fast if done in hardware But: if process grows, may have to be moved (SLOW) UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 15

Memory Allocation n n As processes enter system, grow & terminate, OS must track available and in-use memory Can leave holes n OS must decide where to put new processes UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 16

Memory Allocation Policies n First-fit: n n Best-fit: n n Use smallest hole that’s large enough Worst-fit: n n Use first hole in which process fits Use largest hole What’s best? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 17

Fragmentation n n Fragmentation = % memory unavailable for allocation, but not in use External fragmentation: n Caused by repeated unloading & loading n n n Many small holes No contiguous chunk large enough Internal fragmentation: n Space inside process allocations n Unavailable to other processes UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 18

Compaction n Can make space available by compacting process space n Eliminate holes UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 19

Compaction Example n Issues n n n Amount of memory moved Size of created block Other choices? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 20

Alternative: Swapping n Swapping = copy process to disk, release all memory n n Compaction simplified if swapping supported n n When process active, must reload Static relocation: same position(!) Dynamic relocation: ok But not supported in modern OS’s Interaction with scheduling? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 21

Summary n n Processes must reside in memory to execute Generally use virtual addresses n n Segmentation: n n n Translated to physical addresses before accessing memory Allows processes to share memory Expensive to grow over time Swapping: n n Total being used by all can exceed main memory Increases context switch time UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 22