Memory Management

CSE 410, Spring 2008

Computer Systems

http://www.cs.washington.edu/410

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 1

 Readings and References
• Reading
» Chapter 9, Operating System Concepts, Silberschatz, Galvin, and
Gagne

• Other Readings
» P&H:
» P&H CDA-AQA:

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 2

 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

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 3

 Direct Physical Addressing

physical
addresses

program
addresses
stack
physical
heap memory
program

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 4

 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
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 5
 Absolute Code
• 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)
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 6
 Memory Mapping
program memory physical
addresses mapping addresses
stack

heap
program
physical
stack
memory
heap
program

stack

heap
program disk

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 7

 Address Binding
• 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)
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 8
 Intro to Address Bindings
• Compiler/assembler
• Symbolic -> Absolute
• Symbolic -> Relocatable
• Loader
• Relocatable-> final binding
• Runtime environment
• Relocatable-> final binding

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 9

 Address Generation and Binding
• 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”
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 10
 Address Transformations
• 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).
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 11
 Final Address Binding
• 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!
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 12
 Relocatable Code
• 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
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 13
 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.
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 14
 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
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 15
 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

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 16

 Uniprogramming without Protection
• Application always runs at 0x0000
the same place in physical
memory Edit

• Process can access all

memory even OS
» program bug crashes the unused
machine
OS
• MS-DOS
0xFFFF

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 17

 Multiprogramming without Protection
• When a program is loaded
the linker-loader translates a 0x0000

program's memory accesses Word

(loads, stores, jumps) to
where it will actually be 0x7000

running in memory Solitaire

» Still no protection
• Once was very common unused

• Windows 3.1, Mac OS  9 OS

0xFFFF
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 18
 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"

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 19

 Simple Translation: Base/Bounds

• Each process has a base OS

register
base reg
» added to every memory =0x200000
reference Word
bounds reg
• Each process has a =0x500000

bounds register base reg

=0x600000 Solitaire
» no memory reference
bounds reg
allowed beyond here =0x700000

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 20

 Base/Bounds

Virtual
Address OS

Base Physical base reg

register + Address =0x200000
Word
bounds reg
=0x500000
Bounds yes
register > ERROR!
base reg
=0x600000 Solitaire
• Word references 0x004FF00 - valid bounds reg
• Solitaire references 0x1100C0 - error =0x700000

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 21

 Fragmentation

OS OS OS OS OS OS OS OS OS
compaction
P1 P1 P1 P1 P1 P5 P5

P4
P4 P4 P4
P2 P2
P3
P3 P3 P3 P3 P3 P6

• 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
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 22
 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
02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 23
 Virtual Physical
Paging Page # Page #
0x0000
0 0 0x0000
1 1
• Divide a process's virtual 2 2
address space into fixed- 3 3
size chunks (called pages) 4 4
• Divide physical memory 0x6000
5 5
into pages of the same size 6
• Any virtual page can be 0x0000 7
0
located at any physical 8
1
page 9
2
10
• Translation box converts 0x4000 3
11
from virtual pages to 12
physical pages Translation
13 0xE000
 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

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 25

 Page Tables
virtual physical
address address
Virtual Physical
VPN Page Table PPN
Page # page #
Offset Offset

• A page table maps virtual page numbers to

physical page numbers
• Lots of different types of page tables
» arrays, lists, hashes

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 26

 Flat Page Table Page Table Memory
0 5 0
• A flat page table 1 6 1
uses the VPN to 2 2 2
3 13 3
index into an array 4 10 4
• What's the 5 9 5
6
problem? VPN
7
8
4 100 9
VPN Offset 10
11
12
13
PPN
 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

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 28

 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
» …

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 29

 Multi-level Page Tables
L2Page Tables Memory
L1 Page Table 0
1
0
2
1
3
2
4
3 NO
5
6
7
8
9
10
11
3 2 100
12
VPN Offset 13
 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

02/21/24 cse410-26-memory © 2006-07 Perkins, DW Johnson and University of Washington 31

 Inverted Page Tables
Inverted Page Table Memory
• Inverted page tables
hash the VPN to get Hash
the PPN Table
• Requires O(1) lookup
• Storage is proportional
to number of physical
pages being used not
VPN Offset
the size of the address
space