When a program is first loaded, the logical memory address range of the application is divided into fixed size units called pages. As each page is referenced by a program, it is mapped to a physical page that resides in physical memory. The mapping is dynamic which ensures that logical addresses that are frequently referenced reside in physical memory. Remember that each individual process that is launched is allocated its own virtual address space and application program threads are only permitted to directly access the virtual memory locations that are associated with their parent process’ address space. This is where Page Tables come into play.
Page Tables are built for each process address space. The Page Table maps logical virtual addresses for a process to physical memory locations. The location for a set of Page Tables for a process is passed to the processor hardware during a context switch. The processor refers to the Page Tables to perform virtual to physical address translation as the process threads are executed. At this point, there are a few terms to become familiar with when dealing with Pages and Page Tables:
- Working Set Pages: The active pages of a process currently backed by RAM (also known as Resident Pages)
- NonResident Pages: Virtual memory addresses that are allocated, but not backed by RAM
- Committed Pages: Pages that have Page Table Entries. Committed Pages may be either resident or nonresident
As we mentioned above, Virtual Memory Manager ensures that logical addresses that are frequently referenced reside in physical memory. It does so through the use of a Least Recently Used (LRU) page replacement policy. The VMM also attempts to maintain a pool of free or available pages to ensure that page faults (which we will cover in our next post) are resolved rapidly. When the virtual pages of active processes overflow the size of RAM, the Memory Manager tries to identify pages that are older or inactive that are candidates to be flushed from physical memory and stored on disk. A copy of inactive virtual memory pages is held in the paging file. The operating system checks to see if a page that it temporarily removed from the process working set has been modified since the last time that it was stored in the page file. If the copy in the page file is current, there is no need to re-copy the contents to disk before removing them from physical memory.
All this seems fairly straightforward – and if the Memory Manager is successful in keeping the active pages of processes in RAM then the Memory Manager’s operations do not affect the user experience. However, if there is insufficient physical memory to hold the active pages of running processes, then the system will exhibit performance degradation.
With that, we’re going to wrap up this post. In our next post, we’ll discuss Page Faults. Until next time …
| Share this post : |
|
|
|
|
|