From: Reid Wilkes (reidw_at_microsoft.com)
Date: Wed Feb 11 2004 - 11:26:43 PST
The paper describes the virtual memory system implemented in VAX/VMS.
Knowing that VMS was in many ways a predecessor of Windows, I see
several things about the memory system that seem to resemble aspects of
Windows - although I am not familiar enough with most of the details of
Windows memory management to really be able to compare the two. Reading
this paper was like being an archeologist studying some ancient text -
not because the technology is necessarily dated but because the paper is
nearly illegible. The paper first describes they layout of the virtual
memory space into system and program sections, and assigns meaning to
the individual bits in the 32 bit virtual address. There is a comment I
don't understand about how users call the operating system services just
as they would call any user-written program. Then the next sentence says
that user programs cannot access executive code and data because the
memory pages are protected. There seems to be a disconnect there, the
explanation of which is probably beyond the scope of the paper. The VMS
system introduced implementation 'tricks' to improve the performance of
the VM system. Specifically, the improvements were needed because VMS
was being written to target the more low-end hardware of the day, and
thus was more subject to performance constraints than the bigger
mainframe systems. The first optimization was the maintenance of free
and modified lists of pages that had recently been removed from a
processes' working set. Because these lists were maintained at a certain
length, there was a good chance that a page which had been removed from
the working set but was still needed would still be resident in physical
memory and thus could be returned to the processes' working set without
requiring a disk access. The next optimization was to batch reads and
writes between memory and disk. This was maybe a little hard to do
especially with memory pages going to the paging file but definitely
could be done when loading program images. A final optimization involved
having a swapper process separate from the pager which was responsible
for moving entire processes' working sets into and out of memory as they
were context-switched. This part was not entirely clear to me as I
couldn't quite tell if the swapper moved the processes' pages into same
file as the pager used or if there was a separate file the swapper used.
Another piece I had trouble understanding was the discussion of how
process page tables are dealt with. They are a part of system space, but
yet are added to a processes' resident set when they are faulted. I'm
sure if I understand a little more about how the overall virtual memory
system worked this would be more clear. I guess that means processes'
working sets can contain system as well as user pages?
This archive was generated by hypermail 2.1.6 : Wed Feb 11 2004 - 11:27:05 PST