Virtual Memory Management in the VAX/VMS Operating System (Levy and Lipman, 1982) 
Machine-Independent Virtual Memory Management for Paged Uniprocessor and 
Multiprocessor Architectures (Rashid, et. al. 1987)

Jonathan Ledlie CS 736 March 1, 2000

Although not as flexible as Mach, the VMS VM system can run on a small range of 
hardware and has the capacity to work in batch, real-time, and interactive modes.  
User processes see a 232 byte addressable space, which is simply divided into some 
protection bits, a page number, and an offset.  This opposed to a more layered system 
like on a Sparc.  The lower half of memory belongs to the process and the upper to the 
system – thus each process shares the same view of the system memory (another 
simplification).  Processes which are meant to run in real-time or batch modes are 
given the ability to lock pages in memory so that the process is guaranteed that they 
will be there when it gets the processor again.  Two more interesting ideas are: 1) 
the vectoring level of indirection provided at the top of system memory, allowing 
relocation of system programs and 2) the use of two lists by the pager which 
separately keep track of the clean free pages and the dirty ones, which allows 
“delaying modified-page write requests through the modified page list 
mechanism.”  Two negative points are that keeping the items on this list in memory 
and not writing them out would be troublesome in a crash.  Also, I don’t think the 
swapper is necessarily a good idea because there are many scenarios where this 
would result in more I/O (like when a process is brought back in but only half of it is 
now required, and it has now stepped on someone else – anthropomorphically 
speaking).  Far more flexible is Mach’s VMM which keeps all machine dependencies to 
one .C file in the kernel source.  In keeping with Mach’s microkernel philosophy, 
the application can choose its own paging algorithm.  Each application 
communicates with its memory objects through ports, allowing for better overall 
abstraction.  The primary use of this abstraction, as presented in the paper, is 
copy-on-write, where two processes can have RW access to a chunk of memory, each 
believing that it is its sole owner.  When either one writes to this chunk, only the 
piece that they write to is duplicated, and the kernel handles the bookkeeping 
involved.  This is particularly poignant when a process forks and makes few or no 
changes to its memory.  Mach implements this abstraction with shadow objects: “A 
shadow object collects and "remembers" modified pages which result from 
copy-on-write faults.“  To summarize, Mach is easily portable, smart in its VM 
abstractions, and smart in implementing those abstractions.  Two bad points are 
that the paper only provides microbenchmarks and that, from the Ultrix vs. Mach 
paper, we know that there is some cost to their indirection, which the authors deny 
here.