04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 1
Memory Management
CSE 410, Spring 2008
Computer Systems
http://www.cs.washington.edu/410
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 2
Readings and References
• Reading » Chapter 9, Operating System Concepts, Silberschatz, Galvin, and
Gagne
• Other Readings
» P&H:
» P&H CDA-AQA:
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 3
Review: Program Memory Addresses
• Program addresses are fixed at the time the source file is compiled and linked
• Small, simple systems can use program addresses as the physical address in memory
• Modern systems usually much more complex» program address space very large» other programs running at the same time» operating system is in memory too
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 4
heapprogram
stackphysical
memory
programaddresses
physicaladdresses
Direct Physical Addressing
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 5
Physical Addresses
• Address generated by the program is the same as the address of the actual memory location
• Simple approach, but lots of problems» Only one process can easily be in memory at a time
» There is no way to protect the memory that the process isn't supposed to change (ie, the OS or other processes)
» A process can only use as much memory as is physically in the computer
» A process occupies all the memory in its address space, even if most of that space is never used• 2 GB for the program and 2 GB for the system kernel
Absolute Code
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 6
• Compile time: if it can be known in advance the starting address of a program in memory, then absolute code can be generated.
• .com-format programs (MSDOS)
• Output: a.exe, a.o, or an object module
• Q:In a multiprogrammed environment, can I run two of these synchronously?
• Q: Can I relocate this code (say, to coalesce memory gaps when dealing with fragmentation)
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 7
heapprogram
stack
physical
memory
heapprogram
stack
heapprogram
stack
programaddresses
physicaladdresses
memorymapping
disk
Memory Mapping
Address Binding
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 8
• Symbolic Addresses
• Relocatable Code Absolute Code
• Loader produces the final address binding(no dynamic relocation)
• Run-time environment produces the final address binding (with dynamic relocation)
Intro to Address Bindings
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 9
• Compiler/assembler
• Symbolic -> Absolute
• Symbolic -> Relocatable
• Loader
• Relocatable-> final binding
• Runtime environment
• Relocatable-> final binding
Address Generation and Binding
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 10
• Source code produces symbolic addresses• Array1, x, y, count• An abstraction offered to us by our assembler
• A compiler will bind these symbolic addresses to • Absolute addresses
• Symbolic address was x, absolute (physical address) is 0x04
• Relocatable addresses• Symbolic address was x, relocatable address is
“16 bytes from the beginning of this file”
Address Transformations
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 11
• Load Time
• Loader: ties in other libraries and…
• If we couldn’t deduce our starting address statically, our compiler would generate instead relocatable code
• “14 bytes from the beginning of this file”
• All address bindings would be delayed until loading, at which point a starting offset defines every address in the program (like absolute).
Final Address Binding
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 12
• Done at runtime• Rather than x, which is our second word in the data
section, we might call it “+4bytes from start”• If the starting address isn’t known in advance, then
the relocatable->logical binding is delayed…• Binding at run time, if to be dynamically
relocated during execution• This more complex binding scheme is the only
in which the logical address space and the physical address space differ!
Relocatable Code
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 13
• An O.S. today will dynamically relocate processes from one section of the memory space to another.
• Delay binding of the relocatable addresses till runtime
• Addresses up to this stage will be in some intermediary form, and then will be bound dynamically
• MS-DOS, x86: 4 relocation registers
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 14
Virtual Addresses• The program addresses are now considered to
be “virtual addresses”» Aka, logical addresses
• The memory management unit (MMU) translates the program addresses to the real physical addresses of locations in memory
• The user program never sees the real physical address – always a logical address» A program can create a pointer to 0x05 and store
to that location in memory, read from it, etc.
Logical Memory V.S. Physical Memory• The concept of a logical address space that is mapped
(bound) to a physical address space is central to good memory management.
• Really, this is just another abstraction in which we decouple our program’s internal addresses from the physical array (with physical addresses) that defines main memory.
• It’s the job of the MMU (memory mapping hardware) to sustain this illusion, providing a reliable function whose input is the program’s logical address and whose output is the corresponding physical address
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 15
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 16
Physical Memory Layout
• Contiguous Allocation» Each process gets a single range of addresses» Single-partition allocation
• one process resident at a time
» Multiple-partition allocation• multiple processes resident at a time
• Noncontiguous allocation» Paging, segmentation, or a combination
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 17
OS
Edit
unused
0x0000
0xFFFF
Uniprogramming without Protection
• Application always runs at the same place in physical memory
• Process can access all memory even OS» program bug crashes the
machine
• MS-DOS
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 18
Solitaire
OS
Word
unused
0x0000
0xFFFF
0x7000
Multiprogramming without Protection
• When a program is loaded the linker-loader translates a program's memory accesses (loads, stores, jumps) to where it will actually be running in memory» Still no protection
• Once was very common
• Windows 3.1, Mac OS 9
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 19
Multiprogramming with Protection
• Restrict what a program can do by restricting what it can touch
• User process is restricted to its own memory space» can't crash OS» can't crash other process
• How?» "All problems can be solved with another level of indirection"
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 20
Simple Translation: Base/Bounds
• Each process has a base register» added to every memory
reference
• Each process has a bounds register» no memory reference
allowed beyond here
Word
Solitaire
OS
base reg =0x200000
base reg =0x600000
bounds reg =0x500000
bounds reg =0x700000
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 21
Base/Bounds
• Word references 0x004FF00 - valid
• Solitaire references 0x1100C0 - error
Virtual Address
+
>
Base register
Bounds register
Physical Address
ERROR!
yes
Word
Solitaire
OS
base reg =0x200000
base reg =0x600000
bounds reg =0x500000
bounds reg =0x700000
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 22
Fragmentation
OS
P1
P2
P3
OS
P1
P3
OS
P1
P3
P4
OS
P3
P4
OS
P3
P4
P5
OS
P1
OS
P1
P2
OS
OS
P3
P4
P5
P6
compaction
• Over time unused memory is spread out in small pieces» external fragmentation
• Rearrange memory to make room for the next program» compaction = lots of copying (expensive)» change base/bounds registers for moved programs
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 23
Base/bounds Evaluation
• Advantages of base/bounds» process can't crash OS or other processes
» can move programs around and change base register
» can change program memory allocation by changing bounds register
• Problems with base/bounds» external fragmentation
» can't easily share memory between processes
» programs are limited to amount of physical memory
» doesn’t improve support for sparse address spaces
Paging
• Divide a process's virtual address space into fixed-size chunks (called pages)
• Divide physical memory into pages of the same size
• Any virtual page can be located at any physical page
• Translation box converts from virtual pages to physical pages
012345
0123
012345678910111213
Translation
Virtual Page #
Physical Page #
0x0000
0x6000
0x0000
0x4000
0x0000
0xE000
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 25
Paging and Fragmentation
• No external fragmentation because all pages are the same size» don’t have to rearrange pages
• Sometimes there is internal fragmentation because a process doesn’t use a whole page» some space wasted at the end of a page» better than external fragmentation
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 26
Page Tables
Page TableVirtual
Page #
Physical
page #
virtual addressVPN
Offset
physical address
PPN
Offset
• A page table maps virtual page numbers to physical page numbers
• Lots of different types of page tables» arrays, lists, hashes
Flat Page Table
• A flat page table uses the VPN to index into an array
• What's the problem? VPN
PPN
Page Table
56213109
012345678910111213
012345
VPN Offset
4 100
Memory
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 28
Flat Page Table Evaluation
• Very simple to implement• Don't work well for sparse address spaces
» code starts at 0x00400000, stack starts at 0x7FFFFFFF
• With 4K pages, this requires 1M entries per page table » must be kept in main memory (can't be put on disk)
• 64-bit addresses are a nightmare (4 TB)• Addressing page tables in kernel virtual memory
reduces the amount of physical memory used
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 29
Multi-level Page Tables
• Use multiple levels of page tables» each page table entry points to another page table» the last page table contains the physical page
numbers (PPN)
• The VPN is divided into » Index into level 1 page» Index into level 2 page» …
Multi-level Page Tables
012345678910111213
L1 Page Table
NO
VPN Offset
3 1002
0123
MemoryL2Page Tables
04/11/23 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 31
Multi-Level Evaluation
• Only allocate as many page tables as we need--works with the sparse address spaces
• Only the top page table must be in pinned in physical memory
• Each page table usually fills exactly 1 page so it can be easily moved to/from disk
• Requires multiple physical memory references for each virtual memory reference» TLB masks most of this
Inverted Page Tables
• Inverted page tables hash the VPN to get the PPN
• Requires O(1) lookup• Storage is proportional
to number of physical pages being used not the size of the address space
Hash
Table
VPN Offset
Inverted Page Table Memory