accomplished by combining the system's page tables witheach unique per process set of page tables.User mode threads running inside a process cannotdirectly address memory locations in the system rangebecause system virtual addresses are allocated using Privi-leged mode. This restricts memory access to kernel threadsrunning in privileged mode. This is a form of security thatrestricts access to system memory to authorized kernelthreads. When an application execution thread calls a systemfunction, it transfers control to an associated kernel modethread, and, in the process, routinely changes the executionstate from User mode to Privileged. It is in this fashion that anapplication thread gains access to system virtual memoryaddresses.Commonly addressable system virtual memory locationsplay an important role in interprocess communication, or IPC.Win32 API functions can be used to allocate portions of commonly addressable system areas to share data betweentwo or more distinct processes. For example, the mechanismWindows Server 2003 uses that allows multiple processaddress spaces to access common modules known asDynamically Linked Libraries (DLLs) utilizes this form of shared memory addressing. (DLLs are library modules thatcontain subroutines and functions which can be calleddynamically at run-time, instead of being linked statically tothe programs that utilize them.)
Virtual memory addressingconstraints
The 32-bit addresses that can be used on IA-32-compat-ible Intel servers are a serious architectural constraint. Thereare several ways in which this architectural constraint canmanifest itself. The first problem is running up against theCommit Limit, an upper limit on the total number of virtualmemory pages the operating system will allocate. This is astraightforward problem that is easy to monitor and easy toaddress - up to a point.The second problem occurs when a User process exhauststhe 2 GB range of private addresses that are available for itsexclusive use. The processes that are most susceptible torunning out of addressable private area are database applica-tions that rely on memory-resident caches to reduce theamount of I/O operations they perform. Windows Server2003 supports a boot option that allows you to specify how a4 GB virtual address space is divided between User privatearea virtual addresses and shared system virtual addresses.This boot option extends the User private area to 3 GB andreduces the system range of virtual memory addresses to 1GB.If you specify a User private area address range that islarger than 2 GB, you must also shrink the range of systemvirtual addresses that are available by a correspondingamount. This can easily lead to the third type of virtualmemory limitation, which is when the range of system virtualaddresses that are available is exhausted. Since the systemrange of addresses is subdivided into several different pools,it is also possible to run out virtual addresses in one of thesepools long before the full range of system virtual addresses isexhausted.In all three circumstances described above, running out of virtual addresses is often something that happens suddenly,the result of a program with a memory leak. Memory leaksare program bugs where a process allocates virtual memoryrepeatedly, but then neglects to free it when it is finishedusing it. Program bugs where a process leaks memory inlarge quantities over a short period of time are usually prettyeasy to spot. The more sinister problems arise when aprogram leaks memory slowly, or only under certain circum-stances, so that the problem only manifests itself at erraticintervals or only after a long period of continuous executiontime.However, not all virtual memory constraints are the resultof specific program flaws. Virtual memory creep due to slow,but inexorable workload growth can also exhaust the virtualmemory address range that is available. Virtual memorycreep can be detected by continuous performance monitoringprocedures, allowing you to intervene in advance to avoidotherwise catastrophic application and system failures.Unfortunately, many Windows server administrators do nothave effective proactive performance monitoring proceduresin place and only resort to using performance tools after acatastrophic problem that might have been avoided hasoccurred. This paper discusses the performance monitoringprocedures, as well as the use of other helpful diagnostic toolsfor Windows servers, that you should employ to detect virtualmemory constraints.
Virtual memory Commit Limit.
The operating systembuilds page tables on behalf of each process that is created. Aprocess's page tables get built on demand as virtual memorylocations are allocated, potentially mapping the entire virtualprocess address space range. The Win32 VirtualAlloc APIcall provides both for reserving contiguous virtual addressranges and committing specific virtual memory addresses.Reserving virtual memory does not trigger building pagetable entries because you are not yet using the virtual memoryaddress range to store data. Reserving a range of virtualmemory addresses is something your application might wantto do in advance for a data file intended to be mapped intovirtual storage. Only later when the file is being accessed arethose virtual memory pages actually allocated (or commit-ted).In contrast, committing virtual memory addresses causesthe Virtual Memory Manager to fill out a page table entry(PTE) to map the address into RAM. Alternatively, a PTEcontains the address of the page on one or more paging filesthat are defined that allow virtual memory pages to spill overonto disk. Any unreserved and unallocated process virtualmemory addresses are considered free.