The 2GB Limit: Virtual Memory Limitations

So far we’ve been talking about the limits of memory with respect to the system as a whole. However, a 32-bit processor also means the applications running on it are themselves 32-bit programs. Modern operating systems like Windows use virtual memory to enforce security and stability between running programs. As part of this implementation, the top half of the virtual address space is reserved for use by the operating system itself. This means standard 32-bit programs are limited to using half of the potential virtual address space:

2³¹ = 2,147,483,648 bytes or 2 GB

The other half of the address space is used by the operating system kernel as privileged shared memory areas to allow fast switching to kernel mode without needing to reload memory mappings. This has some important and useful properties for programs. For example, the difference between any two memory locations allocated by the program is guaranteed to fit into a 32-bit signed number without under- or overflow (i.e., Standard C++ ptrdiff_t would not work in all cases for 32-bit programs if they had a full 4 GB address space).

Virtual address space is also used for more than just accessing physical memory. It is used for communication with hardware devices such as the graphics AGP/PCIe aperture, and for memory-mapped file I/O. When the typical PC had 512 MB or one GB of physical RAM, there was still plenty of room in the 2 GB of virtual address space for all these uses in most cases.

As memories got larger, 2 GB of virtual address space became a limiting factor. This was the case for data-intensive database and server applications when their files grew beyond a few MBs into multi-GBs or even Terabytes in size. Microsoft extended the Win32 API with the Address Windowing Extensions⁵ to enable applications to take advantage of the extra physical RAM made possible by 36-bit mode PAE.

Unfortunately, this could be enabled only under special circumstances. AWE enables a 32-bit application to use more than 2 GB of RAM by using the classic technique of “windowing,” but windowing doesn’t get around the fundamental limitations of the system. Because it is complex, windowing is difficult to manage and the extra memory areas cannot be paged to disk.

A more direct proposal was to give back the 32^nd bit to applications. In principle, the concept is fairly simple: a 32-bit application is linked with the Large Address Aware flag (/LARGEADDRESSAWARE) to indicate it will work correctly if it is given memory addresses larger than 2 GB. Since all pointers in the application are already 32 bits, this is a simple condition to meet, assuming the program does not:

1. Use pointer arithmetic that can result in the difference failing to fit into a 32-bit signed integer, or make other assumptions that pointers are always less than 2 GB in size.

2. Override the meaning of the 32^nd bit for other purposes, such as indicating a “handle” vs. a “pointer” (this technique is used by the DirectX SDK’s D3DX9 Effects library by default with the D3DXHANDLE type).

The real limitation of Large Address Aware (LAA) is that the operating system configuration has to support it. Standard Windows configurations assume the kernel has 2 GB of address space to work with. Special boot modes are required to constrain the kernel to less than that in order to allow LAA applications to have more than 2 GB of user address space. This is accomplished by the use of the /3GB switch or the /userva switch in Windows XP, or the IncreaseUserVa Boot Configuration Database element in Windows Vista.⁶

This will reserve up to 3 GB of address space for LAA applications, leaving the kernel with only 1 GB. Many combinations of drivers and software loads can result in out-of-memory conditions for the kernel in this constrained memory boot mode. It is a difficult solution to implement for your average gamer, and is better left for technically savvy IT managers to deploy in special circumstances. Again, this helps with the virtual address space limitations of 32-bit programs, but doesn’t get around the physical RAM limitations.