| Previous | Table of Contents | Next |
Many computer vendors adopted virtual memory in the late 1960s because of the advent of timesharing systems, an evolution of the earlier multiprogramming operating systems. Multiprogramming partitioned the system’s memory into several pieces, with a different program in each partition. When one program was waiting for an I/O operation to complete, another program could be using the processor. If enough programs could be kept in memory, the processor could stay busy all the time. Multiprogramming operating systems then were still basically batch systems.
Timesharing was a variant of multiprogramming, in which each user had an online terminal. Because these were interactive users (meaning the program was driven by the user at the terminal), there was less demand for long periods of processor time and more think time involved. This type of computer can handle more users, so many more pieces of programs must exist in the memory at the same time. Interactive users wanted fast response time, so the need to efficiently manage these multiple pieces was critical. Virtual memory held the hope for doing just that.
The original idea behind a timesharing system was that individual users in various businesses could rent time on a central computer. This was a popular approach, because many smaller businesses could not afford their own computer. Timesharing provided them with the resources of a large computer at a fraction of the cost. Because the computer users were from nonrelated businesses, there was never a need to share information between them.
Virtual memory evolved to support timesharing by giving a separate address space to each user. The memory space of one user was isolated from the memory space of another user, thereby providing a degree of protection between them. When the resources of the computer were switched to operate on the program for another user, a new address space was used. This operation is usually called a process switch, where a process can be thought of as a unit of work for a user in the system.
In the past, a process switch required lots of overhead. Memory tables had to be changed, registers had to be purged, and new data had to be loaded. To accomplish all this work required that many instructions be executed in the processor. The time required to do this became excessive in many of the computers of the mid-1960s, and many individuals were looking for ways to simplify this process and make it more efficient.2
2I was fascinated with the whole subject of virtual memory and decided to pursue this as my research topic at Iowa State University. I was perplexed at how the major computer vendors, including IBM, had taken this simple, elegant idea and twisted it into an overly complex structure. My research effort to find a virtual memory mechanism that required less processor overhead, and therefore better performance, led to the System/38’s single-level store.
Worse yet, the designers of these timesharing systems decided to keep the file system outside of virtual memory. They created two places to store data and programs: the virtual memory and the file system. With this design, the data and programs can only be used or changed if they are in virtual memory. This means that anything in the file system must be moved into virtual memory before it can be used or changed.
In a conventional system, the file manager keeps a directory that relates the name of a file to the location on the disk where the data for the file is stored. The file manager provides an interface to allow programs to “open” a file. The data is then copied into memory buffers, which are usually part of the virtual memory. There, the data can be used and manipulated. When the program is finished with the data, a “close” operation is performed, which causes the data to be moved from the virtual memory back to the file system.
A simple example for this process that most of us can relate to is using a word processor on a PC. We first open the file, which contains the document we want to use, and we watch the hard disk light blink as the document is read into memory. Actually, it is first being read into our virtual memory, and then part of the document is read into memory. At some time in the past, when we configured our PC operating system, we told it how much disk space should be reserved for virtual memory. In the PC world, this space is sometimes called the application swap file. As we are scrolling through the document, we notice the hard-drive light again blinking. As needed, new parts of the document are being read into memory from this reserved disk space.
The act of opening the file has created a second copy of our document. The original copy of the document still exists unchanged on our hard drive. The second copy is in the disk space we reserved for virtual memory. The virtual memory manager in the operating system automatically brings pieces of the document from the reserved disk area into memory as we need them, and puts them back when they are no longer needed. There are actually three copies of some parts of our document, if we count the copy in memory.
When we are finished making changes and close the document, we are asked if we want to save the changes we made. In other words, do we want to take the updated copy in virtual memory and write it back to the permanent location of the file on the disk? If we do, the copy in virtual memory replaces the permanent copy.
The programmer in the virtual-memory implementation just described sees and manages two levels of storage; the file system and the virtual memory are separate. This two-level store also creates overhead in the system. Opening a file causes a disk write to the swap area, and closing a file requires a disk write back to the permanent location. An alternative approach is to have only one copy of the file.
By not having two separate copies, we would not need to reserve disk space for a swap file. With this approach, the entire file system becomes part of virtual memory. The file manager still keeps a directory, but now it relates the name of a file to the location in virtual memory where the data for the file is stored. The open and close operations no longer need to physically copy the entire file from its permanent location on the disk. Just the portion (or record) you are reading or working on is copied to a memory buffer. We often describe this by saying the files are always used “in place,” thereby improving overall system performance.
This one-level storage is exactly what the original inventors of virtual memory had intended, and it is the model of virtual memory we implemented on the System/38. In honor of the original inventors, we decided to call our virtual memory “single-level store.”
| Previous | Table of Contents | Next |