Relocation

A solution that was invented before virtual memory was to write programs in a special way. Any memory location that contained an address was specially marked in the binary file. When the user tried to run the program, the operating system would allocate memory for it somewhere and load the program into that memory area. As it did so, it would "fix up" all the specially marked address references so that they pointed to the correct locations. For example, let us say the original program contained a table of information starting at memory location 700. Another part of the program—say, at location 210—contained the address of the table (i.e., the value 700) and was specially marked as containing an address. The operating system loads this program into memory, beginning at location 30,000. As it does so, it changes the value in location 30,210 from 700 to 30,700, and so on. This process is called relocation.

This scheme allows the computer to load multiple programs in memory at once, in whatever portion of memory is available at the time. Its advantages are that it is simple to implement and does not require any changes to the hardware. But, it also has some serious shortcomings. First of all, because of the way relocation works, the memory allocated to the program must be contiguous. Suppose the user is running a half a dozen small programs at the same time. After some of these programs have exited, programs 1, 3, and 6 are left running. Now the user wants to run a big application, but unfortunately, there may now be nowhere to put it. If the application cannot squeeze into the space that was used by program 2 or by programs 4 and 5 together, then it cannot fit into memory, even though the total number of noncontiguous free blocks of memory may be more than adequate.

Another drawback of this approach is that the size of a running program is limited to the amount of physical memory installed on the machine, minus whatever the operating system has reserved for itself. But, large programs do not normally use all their memory at once. A program with a large address space may only need to access a few thousand instructions and a few thousand bytes of data at a time. It would be more efficient to allocate only a little bit of RAM at a time to such a program and to keep the rest of its address space somewhere else, such as on disk. This is what virtual memory allows us to do.

Virtual Memory

In a virtual memory system, every program runs in its own private address space. Thus, there is no need for any relocation when the program is loaded into memory. A virtual address space can be larger or smaller than the processor's physical memory. In order for this scheme to work, though, virtual memory requires hardware support. First, memory is divided into chunks called pages. A page is the smallest piece of memory that can be allocated to a program. On Pentium platforms, a page is 4 KB. Second, the processor must have a way of turning virtual addresses into real ones.

Processors that support virtual memory, such as the Pentium, can run in two modes. In real mode, addresses refer to physical locations in RAM. Only the kernel is allowed to run in real mode. In virtual mode, every address is "translated" into a physical memory location by means of a page table. For each page in the virtual address space, the page table gives the real address in RAM where the page is located.

Let us see how this applies to the hypothetical program described earlier. This program will run in its own virtual address space, starting at location zero. When the processor loads the program into RAM starting at location 30,000, it sets the page table entry for page 0 to the value 30,000. Now, when an instruction loads the address at virtual location 210, the processor's address translation circuitry actually causes the data to be loaded from physical location 30,210. The value read from that location in memory will be 30,700 (remember, location 210 holds the address of the table, which is 700), the virtual address of the table. If another instruction then tries to access the table by using this 700 address, once again the address translation mechanism will intervene and convert the reference to location 30,700. The user program only deals with virtual addresses; it has no idea in what portion of physical memory it is running. When the processor is in virtual mode, address translation is happening all the time. Every single memory reference is translated. It happens very quickly because translation takes place on board the processor chip.

With a virtual memory scheme, every program has its own page table, maintained by the kernel. And, physical memory allocated to a program need not be contiguous. Our hypothetical program's page table could say, "Okay, page zero begins at real address 30,000; page one begins at 34,000; page two begins at 62,000; and so on." The user program has no idea that it is spread out across physical memory, because it is living in a virtual world and cannot see the real addresses.

With a little extra help from the hardware, we can carry this scheme one step further and completely divorce virtual memory from RAM. Let us say we do not want to load the entire program into RAM at once, so we only load a couple of pages. For those pages we choose not to load, we put a special marker in the page table that says, "This page is not in RAM." Now the user program starts running, and it makes a memory reference to page zero that is translated nicely. It makes a memory reference to page one, and the processor again looks at the page table and finds the corresponding physical address. Then, the program refers to a memory location that falls on page seven, which we did not load into RAM. The address translation circuitry checks the page table, finds the "not in RAM" marker, and generates a page fault. This is a kind of interrupt. The processor stops executing the user program and gives control to the kernel. The kernel looks at certain status registers to figure out where the page fault came from and says, "Oh, this process wants access to its virtual page seven. I will get some RAM here and load in page seven of the program. Now I will fix update the page table, and I will let the program the instruction again." So, control is returned to the user program, and the program continues as if nothing unusual had happened.

With hardware paging support, user programs really do live in a virtual world. Not only do they not know which chunks of RAM they are using, they do not even know which of their pages are in RAM right now and which are sitting on disk! Every time the process tries to reference a page that is on disk, the page is moved to RAM. And, if the process has not touched a page in a while, it might be moved back to disk. By introducing virtual memory, we have provided user programs with a very clean memory abstraction. They need not worry about sharing the address space with the operating system or with other applications. They need not worry about how much physical memory is on the machine. They have an entire virtual address space to use as they like, and the kernel takes care of the implementation details.

One drawback of using the hard drive for virtual memory is that this can keep the hard drive so busy that access to other files is delayed. For systems that involve frequent file accesses but also require virtual memory, it may be advisable to put the swap file (the file containing all virtual memory pages) on a separate drive.