Persistent Virtual Memory

These ideas, especially the idea of treating files as information-hiding modules, will certainly seem strange to many. The reason is that even modern computer science accepts as a fact of life that operating systems, and therefore programming languages, reflect and reproduce the dichotomy that exists at the hardware level between

• a very fast but expensive main memory (RAM) and
• somewhat slower mass memory devices (e.g. hard drives).

(as shown in Figure 4)

These two categories of memory devices exist, and will probably continue to exist into the foreseeable future, because main memory devices based on electronic circuitry are not only faster than mass memory but they are also more expensive and they are usually volatile (i.e. the information is lost when the power supply ceases). Therefore main memory devices are supplemented by mass memory devices both to reduce costs and to guarantee the persistence of the information which is stored on them.

At the hardware level this is a sensible and economically desirable situation. However, as program sizes increased the computational memory space was no longer adequate, which led to the need to extend this by introducing virtual memory. But this only added to the complexity by "stealing" some of the file memory (see Figure 5) in order to increase the size of the computational memory.

As the Multics designers pointed out [9, 10, 11], this solution results in the need for the operating system frequently to copy programs between the main memory and the mass memory devices. But their proposal to allow part of the file memory to be concurrently addressed as virtual memory was even more complex (because of limitations in the addressing mechanisms at the hardware level, in combination with the desire to share file data between processes). Hence most current systems still use variations of the conventional virtual memory mode.

Monads successfully implemented a different and conceptually much simpler solution, in the form of "Persistent Memory" (see Figure 6).

This solution, which eliminates entirely the idea of a separate file system, allows programs directly to address the entire file system via a single addressing mechanism, which solves many problems (e.g. that of the Multics designers) and allows programmers to use the persistent programming paradigm proposed by Atkinson and Morrison [12].

But an implementation is not as straightforward as one might think, because in order to access the content of the virtual memory very large virtual addresses are required. The central issue is then how such large addresses can be efficiently translated by the hardware into much shorter main memory addresses. The Monads system successfully implemented 60-bit virtual addresses, translating these using a hashing technique devised by David Abramson [13, 14]. Abramson and Keedy then showed how this could be extended to function over a local area network [15], and after Keedy accepted a Chair at the University of Newcastle, a PhD student there, Frank Henskens examined this idea in detail and successfully implemented a Monads local area network [16].

With the appearance of the Internet a rethink became necessary. Together with his PhD student Espenlaub at the University of Ulm, Keedy reached the conclusion that a much larger virtual address size was necessary for SPEEDOS and decided on a 256 bit virtual address. By the time of his retirement in 2005 the problem of how to translate 256-bit virtual addresses rapidly into main memory addresses had not been solved, and Keedy decided after retiring first to complete the design of the Timor programming language (see https://www.timor-programming.org/) and then return to this and other outstanding SPEEDOS issues. The solution to the problem of efficiently translating 256 bit virtual addresses appears in Making Computers Secure, volume 1 and also in Making Computers Secure, volume 2 which can be downloaded below. But this can only be understood after other important issues in the design of SPEEDOS have been explained.