virtual memory primitives for user programs

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

Upload: emmanuel-parsons

Post on 31-Dec-2015

19 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Virtual Memory Primitives for User Programs

Virtual Memory Primitives for User Programs

Andrew W. Appel and Kai Li

Presented by Phil Howard

Page 2: Virtual Memory Primitives for User Programs

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

Page 3: Virtual Memory Primitives for User Programs

Programmer Controlled Memory

16 bitaddressspace

17 bitprogramsize

Page 4: Virtual Memory Primitives for User Programs

Programmer Controlled Memory

foo(){}

bar(){

}

main(){ foo(); bar();}

Page 5: Virtual Memory Primitives for User Programs

Compiler Controlled Memory

20 bitphysicalmemory

16 bitaddressspace

Page 6: Virtual Memory Primitives for User Programs

Compiler Controlled Memory

Program Counter

Program Segment

Page 7: Virtual Memory Primitives for User Programs

Compiler Controlled Memory

Call:

push PCload PC with effective address

Return:pop PC

Page 8: Virtual Memory Primitives for User Programs

Compiler Controlled MemoryCall:

push PCpush PSload PS,PC with effective address

push DS

Return:pop DSpop PS,PC

Page 9: Virtual Memory Primitives for User Programs

System Controlled Memory

32 bit address space

1Mphysicalmemory

Page 10: Virtual Memory Primitives for User Programs

System Controlled Memory

CPU MMU RAM

VirtualAddress

PhysicalAddress

Page 11: Virtual Memory Primitives for User Programs

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

Page 12: Virtual Memory Primitives for User Programs

But wait…

Appel and Li want to control memory themselves

Why?

Page 13: Virtual Memory Primitives for User Programs

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

Page 14: Virtual Memory Primitives for User Programs

Concurrent Garbage Collection

HeapFrom To

root

Page 15: Virtual Memory Primitives for User Programs

Concurrent Garbage Collection

HeapFrom To

root root

Page 16: Virtual Memory Primitives for User Programs

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

Page 17: Virtual Memory Primitives for User Programs

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

Page 18: Virtual Memory Primitives for User Programs

Shared Virtual Memory

CPU

Memory

MappingManager

Shared Virtual Memory

CPU

Memory

MappingManager

CPU

Memory

MappingManager

Page 19: Virtual Memory Primitives for User Programs

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

Page 20: Virtual Memory Primitives for User Programs

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

Page 21: Virtual Memory Primitives for User Programs

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

Page 22: Virtual Memory Primitives for User Programs

Extending Addressability

• Persistent Heap with > 232 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 232 objects per invocation

Page 23: Virtual Memory Primitives for User Programs

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

Page 24: Virtual Memory Primitives for User Programs

VM Primitive Performance

Garbage collection for 4096 byte page = 500 sec

Page 25: Virtual Memory Primitives for User Programs

VM Primitive Performance

Page 26: Virtual Memory Primitives for User Programs

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

Page 27: Virtual Memory Primitives for User Programs

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."

Page 28: Virtual Memory Primitives for User Programs

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."