Windows x64 - All the Same Yet Very Different, Part 1: Virtual Memory

I will start the new year with a small series on Windows x64 in which I will explain why 64-bit computing is not only necessary but inevitable. I will then go on to explain in detail where Windows x64 differs from the 32-bit versions and what that means for all those who are responsible for the design, operation and support of 64-bit systems. All the while I will be focusing on terminal servers, but most facts and conclusions are valid for other system types, too.

It is not by chance that Microsoft announced that Windows Server 2008 would be their last server operating system released in 32-bit versions, too. The 32-bit architecture has, like any other architecture, inherent limitations. That by itself would not be so bad. The fact that we are reaching these boundaries today is.

In order to understand why, we need to take a look at the prevailing 32-bit x86 architecture.

Where are we today?

It is called "32-bit" because the processor registers that are used to store memory addresses are 32 bits wide. Since 4,294,967,296 is the largest number that fits into 32 bits, 32-bit processors can only talk to that many memory cells. And yes, 4,294,967,296 bytes are of course equivalent to 4 GB. Thus x86 processors can only address 4 GB of RAM - more only with tricks like PAE.

Unfortunately, around 20% of those 4 GB cannot even be accessed on most systems. Ask those who plugged 4 GB of RAM into their computers and were quite disappointed when only around 3.2 GB showed up in task manager as physical RAM. The upper 800 MB are usually masked by memory-mapped devices such as PCI cards. In general, only server computers are equipped with both a BIOS and device drivers that support remapping this memory to an area above the 4 GB boundary, making all physical RAM accessible to the operating system. You might need to enable PAE in order for this to work, though.

Virtualization? Old hat!

So much for physical RAM. Let us move on to the much more interesting realm of virtual memory. On x86 systems, every process has its own separate virtual address space of 4 GB. This area is, however, divided into two equal parts: 2 GB are reserved for the kernel; only the remaining 2 GB can be used by the process. It is crucial to note that, while each process has its own private 2 GB of virtual address space, the kernel's 2 GB are per system. Just imagine the kernel as just another program with 2 GB of usable address space.

I did not explain yet, what virtual memory even is. Well, here it comes. As I told you, every process has its own private 2 GB of virtual memory to be used in whatever way pleases the programmer. It would, of course, be a great waste of resources to actually allocate every bit requested by an application in physical RAM. Furthermore, memory management is much easier if every program has its own private address space without needing to worry which memory segment might be used by which process. But the real reason for virtual memory is security - only by guaranteeing that processes cannot directly write to any physical memory address, but only to segments allocated to them, can multi-tasking systems be reliable. Errors in one application do not affect other applications, because each application only has access its own virtual memory. This is the oldest virtualization technology I know of in the x86-world.

Virtual memory works by mapping segments, called pages, of virtual memory into physical (or paged) memory in chunks of 4 KB. Large amounts of physical memory can be economized if several processes need the same page in physical memory for read-only access. This is the case with system DLLs that are used by many if not all running processes. By mapping the same page from physical into multiple processes' virtual memory every process has read-only access to the DLL's code. But what happens if one process wants to modify a page shared with other processes? In such a case the operating system uses a technique called "copy on write". When one process tries to write to a shared page, Windows copies that page and makes the copy exclusively available to the process trying to write. All other processes still share the original read-only version of the memory page.

Another important benefit of virtual memory is the ability to move pages from physical memory to a special area on disk, the paging file. And back, of course. By moving seldomly used pages to the page file, the operating system tries to make the most of the scarce resource RAM. If an application needs to access a memory area that has been paged out, that corresponding data is read from disk and stored in a free page in physical memory which is then mapped to the original address of the application's virtual memory. All that takes time, of course. Reading from the hard disk is about 1 million times slower than reading from the RAM. That is the reason why computers slow down so much if they are not equipped with enough RAM to satisfy the needs of the running applications.

But even if enough free RAM is available, a system may still suffer from memory exhaustion. To understand why, we need to dig into the kernel. In the next article in this mini-series I will explain how the kernel uses memory and why this easily leads to memory shortages, especially on terminal servers.

+++ Your opportunity +++ Use Profile Migrator the new sepago product that makes migrating user personalities between different platforms a breeze.! Download your free version now!

10 responses for "Windows x64 - All the Same Yet Very Different, Part 1: Virtual Memory"

This is probably the most

This is probably the most clear explanation of RAM/Virtual Memory/Paging/Page File I have ever read... very good article. I look forward to the rest of the series

I agree with Sam, a very good

I agree with Sam, a very good explaination. Thank you.

[...] a mini-series on

[...] a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the first article I explained key concepts of the x86 platform, namely that user-mode processes each get 4 GB of [...]

Here's a little something

Here's a little something about the memory architecture in Windows 32-bit versus Windows x64. Highly recommended!

http://www.dansdata.com/askdan00015.htm

Very comprehensive well

Very comprehensive well formed article. Thank you for taking the time to educate the rest of us :)

[...] x64, focusing on behind

[...] x64, focusing on behind the scene changes in the operating system. In the first two articles (here and here) I explained key concepts and limitations of the x86 platform: every 32-bit process can [...]

[...] You can also look at it

[...] You can also look at it another way: This technology has been around for ages and is built into every modern operating system. Consider a typical Windows system with several applications running. All of those applications require a common set of system DLLs, like advapi32.dll, ntdll.dll and so on. It would be a waste of RAM to load those system DLLs into memory multiple times. Instead, the OS loads each DLL only once and maps the one set of physical pages into each process’s virtual memory. I have explained this in more detail here. [...]

[...] the name of Helge Klein

[...] the name of Helge Klein who has written an absolutely fantastic seven part series entitled “Windows x64 - All the Same Yet Very Different” in terms that I think most of us can understand. Even if you’re not a big fan of [...]

[...] glad I took the time to

[...] glad I took the time to read them.  Here is another thing I’m damn glad I read recently.  A six part article on Windows x64.  Some very good information in [...]

[...] Just in case you wonder

[...] Just in case you wonder what I might be talking about: read up on 64-bit Windows in my detailed 7-part series whose last article explains registry [...]