It was an interesting discussion I was having with a few teams off late around profiling their applications, troubleshooting some resource consumption issues and the general nature of how Windows internal works when someone made a very interesting comment about “Virtual Memory”. While the comment itself wasn’t very important the apparent misconceptions that are prevalent about “Virtual Memory” on a Windows OS system are wide and huge.
So in this post I wanted to touch base upon some key concepts around memory and ignoring any particular programming framework for a while discuss briefly how does Windows OS itself manage memory within its runtime environment.
Disclaimer
I have simplified things “a lot” in this post. While all that I state is accurate and technically correct I have not delved deeper into certain concepts which would have made this discussion very technical and slightly out of scope.
Context
Most of this discussion is set in the context of Windows NT as original Windows Kernel hasn’t changed too much since its original logic. Yes there have been lots of bug fixes and a raft of additional functionality has been added to it but most of the core logic and algorithms are still the same especially with respect to memory management. For instance even on Windows 7 the user mode and kernel mode (read below) is divided 50-50 with each limited to 8TB! So when I use the term “Windows” in the discussion I am referring to a 32 bit Windows Kernel. I will explicitly specify if I use this term to refer to a newer version or bitness of the OS.
What is Virtual Memory
Before we move on what in your opinion is Virtual Memory?
[yop_poll id=”2″]
If you said anything other than “Virtual Memory is 4GB” then you are not quite correct.
On a 32 bit Windows OS Virtual Memory (also known as Virtual Address Space) simply refers to the virtual address space a 32 bit process can manipulate. In hexadecimal this value as we all know is from 0X00000000 to 0xFFFFFFFF i.e. 4GB
After x86 Intel did launch a 36 bit processor which theoretically allowed Operating Systems and applications to use 64GB of memory. Windows then enabled something called a Physical Address Extension (PAE) mode which gave Windows the ability to work with the entire 36 bits. However even then the Virtual Memory stayed at 4 GB. I will explain this shortly.
Virtual Memory and Memory Manager
As I explained above, the term Virtual Memory simply refers to the total address space a 32 bit Windows Kernel could work with on a 32 bit CPU. This value is constant and static at 4GB. You can add as much physical memory (RAM) as you like on a box but the Virtual Memory will always be 4GB. Further every application that runs on a Windows system believes it has the full 4GB memory space at its disposal to play with!
To phrase it in other terms every application on Windows is at the liberty to manipulate the entire 0X000000 to 0XFFFFFFFF address space. This as you can imagine presents a bit of a challenge as the total physical memory on a box is limited and not every application can be allowed to use the same address location for storing/reading its data. For instance two different applications might each attempt to modify/read a common location within the memory. For obvious reasons such a free to all access model would result in data protection issues and runtime conflicts.
To manage this allocation of actual physical memory between applications Windows uses a rather nifty module called Memory Manager or more accurately Virtual Memory Manager (VMM).
Memory Manager (also called Virtual Memory Manager or VMM) is a module that virtualises the actual physical memory available on a box and exposes it instead as the a virtual memory space as per the current OS bitness and the CPU architecture.
Thus while a machine might only have 2GB of actual physical memory the applications running on the machine would expect to be able to manipulate the entire 4GB address space and it is the job of VMM to provide that abstraction over physical memory which allows these applications to work as if they are running on a true 4GB physical memory enabled system.
To sum it up, this is how the whole arrangement would appear as
Page File
A discussion about memory would not be complete about solving the mystery of the page file now would it! Although you probably have figured out by now where the Page File or the Swap File fits into this model.
When the free percentage of physical memory reaches a certain threshold the VMM starts swapping out pages from the physical memory for inactive applications and moves those pages into a file on the disk called the page file or the swap file(It does this at other instances too but for the sake of simplicity lets just say it does this when memory is scarce). Later when an inactive application becomes active and demands its pages back the VMM carries out the reverse of this process and loads up the pages back into the physical memory from the page file.
Page file is thus a physical file on the hard drive that is used as a temporary state store for inactive yet running applications and is different from virtual memory.
Kernel Mode and User Mode for memory allocation
While the above model worked in theory there was a serious limitation as to how the memory was distributed and managed by the VMM. In the above model the entire physical memory was managed as one heap by the VMM with no implicit protection for Windows Kernel. Thus it was a possible for a user application to inadvertently end up corrupting a block of memory occupied by a system process thus resulting in the famous Blue Screen Of Death or BSOD.
To resolve this problem to some extent the VMM architecture underwent a rather significant change in Windows 2000 which saw the introduction of a “Kernel Mode” and a “User Mode” for memory. This basically segregated the available physical memory into two distinctand equal partitions. The first partition was reserved for user applications and the other was specifically reserved for the OS Kernel itself. Thus in theory a user application now could not corrupt a memory segment occupied by the OS.
PAE Mode and 36 Bit CPU
Sometimes after the release of Windows NT and x86 CPU Intel released a CPU which had a 36 bit computation model. This now theoretically meant that an operating system had at its disposal the means to manage and manipulate 64GB of memory which as compared to 4GB was a significant leap!
This CPU came inbuilt with a mode termed as Physical Address Extension Mode (or PAE mode). As per the definition from MSDN
PAE is an Intel-provided memory address extension that enables support of greater than 4 GB of physical memory for most 32-bit (IA-32) Intel Pentium Pro and later platforms. This article provides information to help device driver developers implement Windows drivers that support PAE.
When PAE mode was introduced by Intel Microsoft responded by changing the way the VMM behaves as opposed to rewriting Windows Kernel. Thus while the Virtual Memory still remained 4GB for a 32 bit Windows OS the VMM was enhanced to support the extended physical memory now available within the computing environment. Having said that a decision was taken to not enable this by default when Windows boots up. To enable Windows (or rather VMM) to work with extended memory a PAE switch was required in the boot.ini file (oh the good old days!).
However significantly even with the extra memory available the applications running on the 32 bit version of Windows 2000 were only able to still work with 4GB of Virtual Memory. The PAE mode and all this extra memory in real terms only would mean that VMM would have to free up the physical memory less often than when the maximum allowed memory was 4GB.
Even with the PAE mode now available Virtual Memory remained static at 4GB thus not bringing any direct enhancement to the OS kernel or the running applications. Instead the VMM was enhanced to be able to manage and allocated upto 64GB of physical memory instead of 4GB.
A special note – Address Windowing Extensions
Some applications such as SQL Server and Exchange simply need greater memory control than is provided by the model described above. At times these applications need to push the boundaries of normal memory execution model and take direct charge of the memory space their processes run in. To enable such applications to work adequately Windows introduced a set of APIs collectively termed as Address Windowing Extensions. Using this feature an application can use more RAM than is available in the User Mode section of physical memory (2GB). However there are two important considerations here
- The total amount of Virtual Memory does not change. It is still limited to 4GB.
- The application code needs to be specifically designed to leverage AWE.
A detailed discussion of AWE and its programing model would be beyond the scope of this post. I have included AWE to complete the discussion on the topic.
So this is a rather succinct and simplistic overview of memory management within Windows. If you would like more details on any aspect of the above then do drop me a note! I hope you enjoyed reading this article.