GlobalAlloc, HeapAlloc, GlobalFree, GlobalLock, LocalLock, GlobalReAlloc, GlobalSize,
VirtualAlloc, VirtualFree, VirtualLock, VirtualProtect, VirtualQuery
Each process is attributed 2 GB of user address space no matter how much physical memory is actually available for the process. Also, all processes use the same range of linear 32-bit addresses ranging from 0000000016-7FFFFFFF16, regardless of what memory is available.
Because of virtual memory, an application is able to manage its own address space without having to consider the impact on other processes in the system.
One benefit of distinguishing between memory and address space is the capability it provides to applications for loading extremely large files into memory. Instead of having to read a large file into memory, Windows NT provides support for the application to reserve the range of addresses that the file needs. Then, sections of the file can be viewed (physically read into memory) as needed. The same can be done for large allocations of dynamic memory through virtual memory support.
Every address in a process can be thought of as either free, reserved, or committed at any given time. A process begins with all addresses free, meaning they are free to be committed to memory or reserved for future use. Before any free address may be used, it must first be allocated as reserved or committed. Attempting to access an address that is either reserved or free generates an access violation exception.
When reserving addresses in a process, no pages of physical memory are committed, and perhaps more importantly, no space is reserved in the pagefile for backing the memory. Also, reserving a range of addresses is no guarantee that at a later time there will be physical memory available to commit to those addresses. Rather, it is simply saving a specific free address range until needed, protecting the addresses from other allocation requests. Without this type of protection, routine operations such as loading a DLL or resource could occupy specific addresses and jeopardize their availability for later use.
To use reserved addresses, memory must first be committed to the addresses. Committing memory to addresses is similar to reserving it—call VirtualAlloc with the dwAllocation parameter equal to MEM_COMMIT. At this point, resources become committed to addresses. Memory can be committed as little as one page at a time. The maximum amount of memory that can be committed is based solely on the maximum range of contiguous free or reserved addresses (but not a combination of both), regardless of the amount of physical memory available to the system.
When memory is committed, physical pages of memory are allocated and space is reserved in a pagefile. That is, pages of committed memory always exist as either physical pages of memory or as pages that have been paged to the pagefile on disk. It is also possible that, while committing a chunk of memory, part or all of that memory will not reside in physical memory initially. Some pages of memory reside initially in the pagefile until accessed. Once pages of memory are committed, the virtual memory manager treats them like all other pages of memory in the system.
In the Windows NT virtual memory system, page tables are used to access physical pages of memory. Each page table is itself a page of memory, like committed pages. Occasionally, when committing memory, additional pages must be allocated for page tables at the same time. So a request to commit a page of memory can require one page commitment for a page table, one page for the requested page, and two pages of space in the pagefile to back each of these pages. Consequently, the time it takes VirtualAlloc to complete a memory-commit request varies widely, depending on the state of the system and the size of the request.
Once addresses have been allocated as either reserved or committed, VirtualFree is the only way to release them—that is, return them to free addresses. VirtualFree can also be used to decommit committed pages and, at the same time, return the addresses to reserved status.
Processes in Windows NT have a minimal set of pages called a working set that, in order for the process to run properly, must be present in memory when running. Windows NT assigns a default number of pages to a process at startup and gradually tunes that number to achieve a balanced optimum performance among all active processes in the system. When a process is running (actually, when the threads of a process are running), Windows NT works hard at making sure that the process has its working set of pages resident in physical memory at all times.
Processes in Windows NT are granted subtle influence into this system behavior with the VirtualLock and VirtualUnlock functions. Essentially, a process can establish specific pages to lock into its working set. However, this does not give the process free reign over its working set. It cannot affect the number of pages that make up its working set (the system adjusts the working set for each process routinely), and it cannot control when the working set is in memory and when it is not. The maximum number of pages that can be locked into a process's working set at one time is limited to 32. An application could do more harm than good by locking pages of committed memory into the working set because doing so may force other critical pages in the process to become replaced. In that case, the pages could become paged to disk, causing page faults to occur whenever they were accessed. Then the process would spend much of its CPU allotment just paging critical pages in and out of memory.
Bear in mind that locking a page of memory in Win32 does not mean that the page will not be paged to disk. On the contrary, it means that, while the process is running, the locked page of memory will be present in physical memory. It is not only possible, but likely, that the entire working set of pages for a process will be paged to disk when the process is idle. When the process wakes up, its working set of pages is immediately paged back into memory, including the VirtualLocked pages.
See also:
Comments: