Virtual Memory Primitives for User Programs Andrew W. Appel and Kai Li Presented by Phil Howard

Virtual Memory A brief history Programmer Control Compiler Control System Control New Applications Concurrent Garbage Collection Shared Virtual Memory Concurrent Checkpointing Persistent Heap Extending Addressing Data Compression Paging Conclusions

Programmer Controlled Memory 16 bit address space 17 bit program size

Programmer Controlled Memory foo() { } bar() { } main() { foo(); bar(); }

Compiler Controlled Memory 20 bit physical memory 16 bit address space

Compiler Controlled Memory Program Counter Program Segment

Compiler Controlled Memory Call: push PC load PC with effective address Return: pop PC

Compiler Controlled Memory Call: push PC push PS load PS,PC with effective address push DS Return: pop DS pop PS,PC

System Controlled Memory 32 bit address space 1M physical memory

System Controlled Memory CPUMMU RAM Virtual Address Physical Address

System Controlled Memory System handles page faults Allowed protection You can't see my pages You can't change my pages I can't execute my data I can't change my program Made life much easier for programmers

But wait… Appel and Li want to control memory themselves Why?

User access to VM primitives TRAP - Handle page fault PROT1 - Protect a single page PROTN - Protect many pages UNPROT - Unprotect single page DIRTY - return list of dirty pages MAP2 - Map a page to two addresses

Concurrent Garbage Collection Heap FromTo root

Concurrent Garbage Collection Heap FromTo root

Concurrent Garbage Collection Mutator sees only to-space pointers New objects contain to-space pointers only Objects in to-space contain to-space pointers only Objects in from-space contain from-space and to-space pointers Invariants

Concurrent Garbage Collection Use VM to protect from-space Collector handles access violations, validates objects and updates pointers Collector uses aliased addresses to scan in background

Shared Virtual Memory CPU Memory Mapping Manager Shared Virtual Memory CPU Memory Mapping Manager CPU Memory Mapping Manager

Shared Virtual Memory Coherent across processors - each read gets the last value written Multiple readers/Single writer Handled the same as "regular" VM except for fetching and writing pages

Concurrent Checkpointing Stop all threads Save all thread states Save all memory Restart threads Stop all threads Save all thread states Make all memory read-only Restart threads Save pages in the "background" and mark as read/write

Persistent Heap Heap survives across process invocations Read/Write access as fast as conventional heap Use memory mapped disk file Page faults fetch from heap file instead of system page file

Extending Addressability Persistent Heap with > 2 32 objects Need translation table to convert from 32 to 64 bit address Page fault fetches from Persistent Heap and sets up translation Application limited to 2 32 objects per invocation

Data Compression Paging Paging is slow - 20 ms seek time on disk plus transfer time Many data pages can be compressed 4:1 Instead of swapping out a page, compress it Page fault to compressed page will decompress it rather than read from disk

VM Primitive Performance Garbage collection for 4096 byte page = 500  sec

VM Primitive Performance

OS Authors didn't pay much attention to VM Performance Why? Seek time ~ 20 msec Read time ~ 1 msec Page fault happens in parallel with another task Why do we care? Many of the algorithms in this paper don't involve the disk

Conclusions "… page-protection and fault-handling efficiency must be considered as one of the parameters of the design space." "It is important that hardware and operating system designers make the virtual memory mechanisms required by these algorithms robust, and efficient."

Conclusions "… page-protection and fault-handling efficiency must be considered as one of the parameters of the design space." "It is important that hardware and operating system designers make the virtual memory mechanisms required by these algorithms robust, and efficient."