Persistent Virtual Memory

In early computer systems programs were loaded into the main memory for execution while persistent information (i.e. file data and programs) was held in a persistent secondary memory (e.g. drum or disk). To overcome the space limitations of small expensive main memories the designers of Atlas proposed the idea of virtual memory. A conventional virtual memory is functionally an extension of the main memory of a computer, used as a computational memory. But because a separate file memory is still required for storing long-term information this organization of the memory leads to a considerable duplication of mechanisms (for disk space organization, protection, synchronization, etc.) and, as the Multics designers pointed out, to much unnecessary copying of information between the virtual memory and the file system.

To eliminate these problems Prof. Keedy, together with his research students John Rosenberg and David Abramson, introduced the idea of a uniform persistent virtual memory. The Monads II system included a prototype implementation and later a full scale version appeared in the Monads-PC systems. In this model of virtual memory there is no separate file system; both persistent and computational information reside in a single virtual memory with a single address range. The historical development is illustrated schematically in the diagram.

Multics had attempted to implement this basic concept using hardware with 32 bit virtual addresses, with the result that addresses in the virtual memory could not be unique. This led to a very complicated scheme for "making segments known". (In Multics segments are equivalent to files) . At about the same time as the Monads II system was completed IBM announced the System/38, which also supported a form of persistent virtual memory, but this too was complicated by the fact that virtual addresses were only 48 bits wide.

The Monads-PC virtual addresses were 60 bits wide and were unique across the system, with the result that the operating system was very much simpler.

The basic hardware address translation scheme (as originally implemented in Monads II) is described in:

Abramson, D.A. "Hardware Management of a Large Virtual Memory", Proc. 4th Australian Computer Conference, 1981, pp. 1-13.

and the software organization in:

Rosenberg, J. and Keedy, J.L. "Software Management of a Large Virtual Memory", Proc. 4th Australian Computer Science Conference, Brisbane, 1981, pp. 173-181.

An overview of the Monads-PC implementation appears in:

Rosenberg, J., Keedy, J.L. and Abramson D.A. "Addressing Mechanisms for Large Virtual Memories", The Computer Journal, 35, 4, 1992, pp.369-375.

An important advantage of this technique, in addition to its hardware and operating system design advantages, is that it provides direct and straightforward support for persistent programming, i.e. persistent data structures and computational data structures typically supported in programming languages can be programmed in a uniform manner.

An interesting problem with a persistent virtual memory is maintaining its stability. The Monads approach to this is described in:

Rosenberg, J., Henskens, F.A., Brown, A.L., Morrison, R. and Munro, D. "Stability in a Persistent Store Based on a Large Virtual Memory", in Proc. International Workshop on Computer Architectures to Support Security and Persistence of Information, Springer-Verlag, pp. 229-245, 1990.