48

Chapter 4. Physical and Virtual Memory

A later approach known as overlaying attempted to alleviate the problem by allowing programmers

to dictate which parts of their application needed to be memory resident at any given time. In this

way, code that was only required once for initialization purposes could be overlayed with code that

would be used later. While overlays did ease memory shortages, it was a very complex and error 

prone process. Overlays also failed to address the issue of system wide memory shortages at runtime.

In other words, an overlayed program may require less memory to run than a program that is not

overlayed, but if the system still does not have sufficient memory for the overlayed program, the end

result is the same   an out of memory error.

Virtual memory turns the concept of an application's address space on its head. Rather than con 

centrating on how much memory an application needs to run, a virtual memory operating system

continually attempts to find the answer to the question, "how little memory does an application need

to run?"

While it at first appears that our hypothetical application requires the full 15000 bytes to run, think

back to our discussion in Section 4.1 Storage Access Patterns   memory access tends to be sequential

and localized. Because of this, the amount of memory required to execute the application at any given

time is less than 15000 bytes   usually a lot less. Consider the types of memory accesses that would

be required to execute a single machine instruction:

The instruction is read from memory.

The data on which the instruction will operate is read from memory.

After the instruction completes, the results of the instruction are written back to memory.

The actual number of bytes necessary for each memory access varies according to the CPU's archi 

tecture, the actual instruction, and the data type. However, even if one instruction required 100 bytes

of memory for each type of memory access, the 300 bytes required is still a lot less than the appli 

cation's 15000 byte address space. If a way could be found to keep track of an application's memory

requirements as the application runs, it would be possible to keep that application running while using

less than its address space.

But that leaves one question:

If only part of the application is in memory at any given time, where is the rest of it?

4.3.2. Backing Store   the Central Tenet of Virtual Memory

The short answer to this question is that the rest of the application remains on disk. This might at

first seem to be a very large performance problem in the making   after all, disk drives are so much

slower than RAM.

While this is true, it is possible to take advantage of the sequential and localized access behavior of

applications and eliminate most of the performance implications of using disk drives as backing store

for RAM. This is done by structuring the virtual memory subsystem so that it attempts to ensure that

those parts of the application that are currently needed   or likely to be needed in the near future  

are kept in RAM only for as long as they are needed.

In many respects this is similar to the relationship between cache and RAM: making a little fast storage

and a lot of slow storage look like a lot of fast storage.

With this in mind, let us look at the process in more detail.

4.4. Virtual Memory: the Details

First, we should introduce a new concept: virtual address space. As the term implies, the virtual

address space is the program's address space   how much memory the program would require if it