From: Ian King (iking_at_killthewabbit.org)
Date: Wed Feb 11 2004 - 13:51:18 PST
The authors discuss the memory management strategy for the VMS operating system,
intended for use on the VAX line of computers. VAX was an extension of the
PDP-11 architecture primarily intended to overcome memory addressing limitations
in the PDP-11; the older computer was limited to 4MB of physical memory, and
various operating systems had employed strategies to make best use of that
space. The VAX computer included hardware to implement virtual memory, and VMS
did so to provide a virtual memory address length of 32 bits.
VMS was extraordinary because of the leap it represented in memory management at
a time in technological history when a few megabytes of core memory (using the
term metaphorically) was a major investment in both money and hardware design.
Prior to VMS, systems would usually either swap entire processes in and out,
placing them on a storage device while inactive, or load programs in overlays,
allowing a segment of the application code to be replaced with another segment
when required. Both could often require a great deal of disk activity, and
neither addressed the fundamental limitation of memory size - it was nearly
impossible for an object to exceed physical memory size. Ultimately, programs
were written in terms of physical memory space and, with all the tricks used to
segment and partition both code and data, complexity created challenges for
reliability and correctness.
VMS abstracted the concept of a memory address away from physical addresses in a
way that redefined how memory and backing store were used by programs. While
the roots of this idea can be seen back as far as THE (Dijkstra), VMS employed
it to simplify both OS and application functioning. Programs could now be
written without much concern for limits of memory - the use of physical memory
was transparent to the application programmer. With 4GB of virtual memory
space, VMS lopped off a huge segment of it and called it system space - in a
physically-addressed machine, such profligate committed use of address space
would have been unthinkable. Further, because virtual memory was defined through
a dynamic mapping, VMS took advantage of this to map system space into every
process' memory space - a system object pointer would always be valid. There is
even a reference to page faulting as a program load strategy that appears later,
in the Opal system.
VMS also supported swapping, and provided both automated and
programmer-controlled mechanisms to decide which strategy best suited a
particular installation and its hardware. There were also various mechanisms to
ensure that one did not deadlock, i.e. waiting to page in code that controls
paging. These mechanisms could also be used for time-critical code, e.g.
real-time systems.
If there is any question as to the vintage of this paper, one only need examine
the photos of the authors - great hair, Hank. :-)
This archive was generated by hypermail 2.1.6 : Wed Feb 11 2004 - 14:16:14 PST