Lesson 7 - The Virtual Memory Manager

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
On This Page

What You Will Learn
Thinking Ahead
What To Do
Before Going On
Speaking The Language
To Learn More

What You Will Learn

By the end of this lesson, you should be able to do the following:

  • Explain the basic concepts related to virtual memory, virtual and physical addresses, address mapping, swapping, segments, pages, and page faults.

  • Explain how Windows NT 32-bit flat memory model allows programs to be smaller and faster than programs written for a 16-bit segmented memory model.

  • Explain how the virtual memory system is used to implement separate address spaces, shared memory, and mapped files.

Using material learned in this module, you'll be able to explain the following:

  • Why Windows NT doesn't use twice as much memory when running two copies of the same application.

  • Why some programs need a lot of memory to perform well even though there's plenty of disk space available for virtual memory.

Thinking Ahead

What To Do

General Memory Management Concepts

Early operating systems did little more than load an application into memory and start it running. Once running, the application had direct access to, and control over, the computer's physical memory. As operating systems advanced, responsibility for management of the computer's memory migrated from individual applications to the operating system itself.

Modern operating systems generally perform at least a few common functions:

  • Allow multiple applications to coexist in the computer's physical memory.

  • Use virtual addressing to hide the management of physical memory from applications.

  • Extend the system's memory capacity via swapping.

This lesson will begin with a brief review the concepts behind these common memory management functions.

Sharing A Computer's Physical Memory

Operating systems that support multitasking allow code and data from multiple applications to exist in the computer's physical memory ( random access memory) at the same time. It is the operating system's responsibility to ensure that physical memory is shared as efficiently as possible, and that no memory is wasted. As a result, an operating system's memory manager must contend with a problem called memory fragmentation . Memory fragmentation refers to the situation where free (available) memory becomes broken into small, scattered pieces that are not large enough to be used by applications (Figure 1). In the example shown here, free memory is separated into three separate blocks.

Once free physical memory becomes fragmented, an operating system can consolidate free memory into a single, unfragmented block by moving code and data to new physical addresses (Figure 2). In this case, the three blocks of free memory were consolidated into one larger block by moving system memory upward and application 1 downward in physical memory.

If an application accesses its code or data using physical memory addresses, the application may encounter problems when the operating system moves its code and data. A mechanism must be provided for applications to access their code and data no matter where the operating system moves them in physical memory.

Virtualizing Access to Memory

A common solution is to provide applications with a logical representation of memory (often called virtual memory ) that completely hides the operating system's management of physical memory. Virtual memory is an illusion that the operating system provides to simplify the application's view of memory. Applications treat virtual memory as though it were physical memory. Meanwhile, the operating system can move code and data in physical memory whenever necessary.

In a virtual memory system, the addresses applications use to access memory are virtual addresses , not physical memory addresses. Every time an application attempts to accesses memory using a virtual address, the operating system secretly translates the virtual address into the physical address where the associated code or data actually resides in physical memory (Figure 3). Because the translation of virtual addresses to physical addresses is performed by the operating system, applications have no knowledge of (or need to be concerned with) where their code and data actually reside.

Extending Virtual Memory Through Swapping

When applications access memory using virtual addresses, the operating system is responsible for translation of virtual addresses to physical addresses. As a result, the operating system has total control over where data and code are physically stored. This not only means that the operating system can move code and data in physical memory as it likes, but it also means that code and data don't need to be stored in physical memory at all!

A computer's processor can only access code and data that resides in physical memory (RAM). However, physical memory is relatively expensive so most computers have relatively little of it. Most multitasking operating systems extend their virtual memory management schemes to compensate for this scarcity of physical memory. They rely on a simple, but very important fact: Code and data only need to be in physical memory when the processor needs to access them! When not needed by the processor, code and data can be saved temporarily on a hard disk (or other device with abundant storage). This frees physical memory for use by other code and data that the processor needs to access. The process of temporarily transferring code and data to and from the hard disk to make room in physical memory is called swapping (Figure 4).

Swapping is performed to increase the amount of virtual memory available on the computer. The memory manager performs swapping "behind the scenes" to make it appear as though the computer has more physical memory than it actually does (Figure 5). Effectively, the virtual memory available on a computer is equal to its physical memory plus whatever hard disk space the virtual memory manager uses to temporarily store swapped code and data.

Loading Swapped Code And Data On Demand

If an application attempts to access code or data that is not in physical memory (it was swapped to disk) the virtual memory manager gets control. The virtual memory manager locates (or creates) an available block of physical memory, and copies the required code or data into the block so it can be accessed. Applications are not aware that their code and data were ever swapped to disk. The code and data are automatically loaded into physical memory by the virtual memory manager whenever the application needs to use them.

The Windows NT Virtual Memory Manager

In Windows NT, responsibility for managing the relationship between the virtual organization of memory (as seen by applications) with the physical organization of memory (as seen by the operating system) falls on a component of the Windows NT executive called the virtual memory (VM) manager .

Memory Management Goals

Windows NT is a portable, secure, multithreaded, multiprocessing operating system. As a result, its virtual memory manager must:

  • Be compatible with multiple processor types

  • Protect the NT Executive from applications

  • Protect applications from each other

  • Provide mechanisms for programs to efficiently share physical memory (RAM).

  • Be efficient

An Application's View of Memory

In Windows NT, applications access memory using a 32-bit linear addressing scheme. This scheme is sometimes referred to as flat memory model because applications view memory as one linear (or flat) array of memory locations. Applications address memory using simple 32-bit offsets from address zero (0). Since a 32-bit offset can specify 232 memory addresses, each application can access up to 4 Gb of (virtual) memory. The range of addresses an application can access is called the application's address space (Figure 7).

The 32-bit flat memory model makes Windows NT portable because it is compatible with the memory addressing of processors such as the MIPS R4000 and DEC Alpha. It also simplifies porting of applications originally written for flat memory model environments such as Unix and the Apple Macintosh.

The flat memory model used in Windows NT contrasts sharply with the segmented model used in Windows for MS-DOS. In Windows for MS-DOS, memory is broken into many differently sized segments, each with a maximum length of 64K. This has been a major difficulty for developers of Windows applications for a very long time because changing segments is somewhat difficult and slow. This difficulty has led to many 64K limits in a lot of software, including the Windows 3.1 resource heap. The 32-bit flat memory model does away with all of these constraints.

Protecting The NT Executive From Applications

Windows NT is designed to be secure and very reliable. One way that it ensures security and reliability is by protecting the NT Executive's memory (code and data) from direct access by applications. Protection is achieved by assigning the NT executive's memory a privileged status. Code in the NT Executive has adequate privilege to access the NT Executive's memory, but code in normal applications is denied this privilege.

The 32-bit flat memory model allows an application to address up to 4Gb of memory; that is, the application has a 4Gb virtual address space. The memory at each virtual address has a privilege level associated with it. Memory in the upper 2Gb of the address space can only be accessed by privileged (kernel mode) code (that is, code in the NT Executive). Memory in the lower 2Gb of the address space can be accessed by unprivileged (user mode) code (such as normal applications) and by privileged code. Because the NT Executive resides exclusively in the upper 2Gb of memory, it is protected from direct access by normal applications (Figure 8).

Because applications can not directly access the NT Executive's code and data:

  • Misbehaved applications can not accidentally corrupt the system.

  • Hostile applications can not intentionally steal system information or modify the system's behavior.

Protecting Applications From Each Other

Supporting Windows NT's goals of security and reliability also requires that applications be protected from each other. Windows NT ensures that one application can not access another application's memory unless both applications cooperate.

The virtual memory manager maintains data structures that allow it to translate virtual addresses to physical addresses. Though several data structures are involved in the translation process, the purposes of the individual data structures are beyond the scope of this course (for more information see "An Introduction to Windows NT Memory Management Fundamentals", Paul Yao, Microsoft Systems Journal, Vol. 7, No. 4). For convenience, they'll be referred to here generically as address translation tables (Figure 9).

The virtual memory manager maintains separate address translation tables for each process. The tables contain entries that determine how virtual addresses are translated to physical addresses, and therefore which pages of physical memory the process is allowed to access. The address translation tables for two or more processes will only reference the same page of physical memory in special cases. As a result, each process' physical memory is generally protected from all other processes (Figure 10).

Suppose that two processes both try to read the memory at the same virtual address. Each process has its own address translation tables, so the virtual address might translate to physical address 20 for one process and physical address 2000 for the other process. Unless special arrangements are made for the two processes to share memory, they will always access different pages of physical memory, even if they use the same virtual addresses.

Sharing Memory Between Processes

There are times when more than one process needs to access the same page(s) of physical memory. For example, two applications that work cooperatively might store a shared data structure in a section of memory that they can both access. The virtual memory manager makes special arrangements that allow processes to share memory. It adjusts the address translation tables for both processes so that virtual addresses in both process' address spaces translate to the same physical pages of memory (Figure 11).

Synchronizing Access To Shared Memory

When threads in different processes share memory, they must synchronize their access to the memory just as two threads within the same process must synchronize their access. The Windows NT executive supplies synchronization objects that provide the basic mechanisms threads needed to manage this synchronization.

Benefits of Shared Memory

Applications that share physical memory trade the protection of separate address spaces for efficiency of communication. When applications share memory, they can have instantaneous access to each others' data. Of course, this access carries responsibility because it is relatively easy for one application to corrupt the data it shares with another application..

Sharing memory can also reduce the consumption of physical memory. For example, if 5 instances of an application are running at the same time, all 5 of the applications can execute the same code. Only one copy of the code must be stored in physical memory. However, if Windows NT did not allow any sharing of memory between processes, it would be necessary to maintain 5 copies of the application's code in physical memory.

Page-based Memory Management

When the computer's physical memory is in high demand, the virtual memory manager is responsible for swapping (copying) code and data to disk for temporary storage. The virtual memory manager then copies the code and data back into physical memory as it is needed.

The virtual memory manager manages memory in fixed length (4Kb) units called pages . The disk-based files in which pages are stored are called page files . Physical memory and page files are both treated as arrays of pages (Figure 12).

Pages can be copied between page files and physical memory efficiently because all pages are the same size. Any available space in physical memory or the page file can accommodate a page transferred from the other.

When pages are copied from physical memory to a page file, the address translation tables used to access the pages are marked to indicate that the pages are not in physical memory. When an application attempts to access a page that is not in physical memory, a fault occurs. In response, the virtual memory manager copies the required page from a page file to an available page of physical memory. The virtual memory manager then updates the address translation tables to indicate where the page is located in physical memory. Once the address translation tables have been updated, the application can successfully access the page.

Support For Multiple Page Files

When the virtual memory manager needs to make more physical memory available, it can copy code or data from pages in physical memory to pages in one or more page files (Figure 13).

If the page files exist on separate physical disks the pages can be written to many files simultaneously. This type of arrangement can be used to increase paging performance.

Mapped File I/O

The Windows NT virtual memory manager also provides an efficient mechanism for processes to share and access files. This mechanism is called mapped file I/O . In effect, mapped file I/O allows a disk-based file to be accessed by processes using normal virtual memory addressing mechanisms.

To use mapped file I/O, a process specifies which portion of a file it wants to access, and which range of virtual addresses it wants to use to access the file. In Windows NT, relating a range of virtual addresses to the portion of the file they'll be used to access is called mapping a view of the file. Once a process has mapped a view of a file, it can access the file simply by reading from or writing to the virtual addresses in the view. This allows the code that performs file I/O to be much simpler than code that uses traditional file I/O functions.

Behind the scenes, mapped file I/O is provided by the virtual memory manager. The virtual memory manager treats a mapped file in much the same way it treats a paging file. When pages of a mapped file are needed by a process, the virtual memory manager pages them from the disk to physical memory. When physical memory becomes scarce, the virtual memory manager copies modified pages of the file from physical memory to the disk (Figure 14).

Uses for Mapped File I/O

Consider an application that needs to access data stored in a massive database file. The application can use mapped file I/O to selectively map views of small portions of the database file. The application can then use the small views to access the portions of the database that it needs. It does not have to load the entire file into physical memory. In addition, several copies of the application could map and use views of the database file simultaneously (Figure 15).

Internally, Windows NT uses mapped file I/O to load applications' code and data into memory. When the first instance of an application is run, Windows NT loads the application's code into memory and maps a view of it into the address space of the newly created process. However, when additional instances of the same application are run, Windows NT simply maps the existing code (in physical memory) into the new process' address space. Memory mapped files make loading additional instances of an application a relatively fast operation.

Before Going On

Before you go on, make sure you can answer the following questions:

  1. Why is virtual memory an essential feature of most modern operating systems? What is the basic principle behind virtual memory?

  2. What are virtual and physical addresses? How are virtual addresses mapped to physical addresses?

  3. What does a virtual memory operating system do when a program tries to access memory at an address that's not in physical memory? What is this situation called?

  4. What does a virtual memory operating system do when a program requests a page (for instance, to load a program) when no page is currently available?

  5. What are the advantages of a virtual memory system that swaps pages rather than segments?

  6. What are the differences between the linear (flat) and segmented models of virtual memory? What are advantages of linear model? Which Microsoft operating systems use which models? Can segmented model use page swapping?

  7. How big is a Windows NT application's virtual address space? Why isn't it bigger?

  8. How does the virtual memory system create separate address spaces for each process? How does the processor switch address spaces when it switches between processes?

  9. How do two processes in two different address spaces share memory? What must processes that share read-write memory do to ensure that they don't modify the memory incorrectly?

  10. What are mapped files and views of mapped files? How is the virtual memory system used to implement mapped files?

  11. Why does Windows NT take steps to minimize swapping?

Speaking The Language

This lesson introduced terms that it is important for you to understand. Please look through the list and verify that you understand the meaning of each term:

  • Virtual memory (VM) manager

  • Memory fragmentation

  • Physical memory

  • Virtual memory

  • Physical addresses

  • Virtual addresses

  • Address space

  • Flat memory model

  • Swapping

  • Pages

  • Page files

  • Mapped file I/O

  • Mapping a view

  • Synchronization objects

To Learn More

If you're interested in learning more about this topic, you may find the following resources useful:

  • Inside Windows NT, Chapter 6.