Virtual Memory Art Munson CS614 Presentation February 10, 2004

VM Review 0164 Physical Memory Virtual Memory (seen by application) Efficient Translation?

VM Review (II) 0164 Physical Memory Virtual Memory (seen by application) Virt. Page Phys. Frame …… 6Fr 2 1Fr 3 TLB Page Table Lookup page Found ? No Yes

VM Pros/Cons More address space –Per program –System-wide Isolation / Protection Ease of Cleanup Complicates sharing memory Performance: –Context switches (cache, TLB) Motivation: multiple interactive programs on one computer

Mach Goals Portable: uniproc, multiproc, and distributed computers Support large, sparse virtual address space Copy-on-write as VM operation Efficient copy-on-write & read-write memory sharing

Mach Goals (cont’d) Memory mapped files Allow generic user-provided backing store objects (and pagers)

Mach Memory Architecture CPUPhys. Memorypmap Machine Dependent Code RW/C R/CRW/N X/S Ref: 3Ref: 1 Kernel Address map Memory objects Pagers ??

Key Architecture Decisions Memory Objects Data. Anywhere. Associated pager maps to address space(s). Message Passing Loosely coupled, allowing generality. Simple semantics allows consistent API for distributed computing. Too simple?

Implementing Memory Sharing Shadow objects: proxies to support copy-on-write at page granularity. Shared mapping: provides coherency for read-write sharing AB C

Page Table Tradeoffs Normal: due to large size (8MB), linear organization non- option Pg 0Fr 2 Pg 1Fr 0 Pg 2Disk …… Pg 0Fr 2 Pg 1Fr 0 Pg 2Disk …… Pg 0-3 Pg 3-6 … Inverted: query with hash function. Aliasing clumsy / expensive Fr 0Pg 1 Fr 1empty Fr 2Pg 0 Fr 3Pg 6

Mach VM Performance

Mach VM Performance (II)

Clever VM Hacks Idea: use page fault hardware to check simple application predicates. OS provides hooks for application: TRAP, PROT1, PROTN, UNPROT, DIRTY, MAP2 Implicit assumption that faulting page is in memory---i.e. app handles protection faults.

Pointer Forwarding From-space To-space

Pointer Forwarding (II) From-space To-space

Hack #1: Concurrent Garbage Collection From-space To-space 1.Initialize collecting: a.Stop mutator threads. b.PROTN collection region. c.MAP2 region so collector can access (not shown). d.Copy roots & registers to to-space. e.Restart mutator threads. f.Collecting thread starts scanning from-space.

Hack #1: Concurrent Garbage Collection (II) From-space To-space Page fault void trap_fault(pg) { objList = scanPage(pg); foreach (o in objList) { copy o to to-space forward ptrs to o } UNPROT(pg); rerun faulting instr. }

Hack #2: Shared Virtual Memory

Hack #2: Shared Virtual Memory (II) CPU 1 CPU 5 aBcdefgh ijkBmfwh Give me up-to-date copy of B; Then invalidate the page. Here you go. CPU 1 now marks B as writeable and resumes execution. CPU 1 faults when trying to write read-only B.

Hack #3: Concurrent Checkpointing Goal: save application state (registers + memory). Algorithm: Mark all pages read-only ( PROTN ). Background thread concurrently copies pages to checkpoint, then marks read/write. On write-fault, checkpoint thread backs up faulting page and marks writeable.

Other VM Algorithms Generational garbage collection Persistent stores Extending address space in persistent stores Data compression paging Heap overflow detection

VM Primitive Performance

Is this a good idea? View 1: Extending VM services provided by OS Reduces instruction count => better perf* Data properties determine program execution. Mach model easy logical fit. So OS designers should improve efficiency of VM primitives.

Is this a good idea? (II) View 2: Relies on knowledge of hardware, not an abstraction. Introducing more page faults might degrade performance on current highly pipelined processors. Able to enforce not looking at CPU state? OS: trust application code?

Summary Rich set of memory abstractions enables VM for uniproc and multiproc computers. –Distributed computing tolerant of abstraction in practice? Clever VM hacks may not adjust well to hardware changes.