A Messy Transition: Practical Problems With 32bit Addressing In Windows
by Ryan Smith on July 12, 2007 12:00 PM EST- Posted in
- Software
In 1986, Intel released the 386 processor, which offered support for a new instruction set (IA32), that was an extension of the original x86 instruction set. Among the most notable features in IA32 was an increase in the amount of memory the CPU could address, moving from 20bit addressing(1MB) to 32bit addressing(4GB)(ed: this is not including the convoluted mess that was segmented addressing). All x86 CPUs released since then have supported the same instruction set, including the same 4GB limit. Only recently have 64bit x86 CPUs been released, and while they support more than 4GB of memory, still are limited to 4GB when operating in 32bit mode.
As we have mentioned in previous articles, most modern system running in 32bit x86 mode have trouble seeing and using more than roughly 3GB of memory. This is because part of the total 4GB of memory space (not the physical memory) is reserved for various functions, such as computer components transferring data between each other using memory-mapped input-output(MMIO). The textbook example of this is the CPU transferring data to the memory of a video card, where a chunk of the address space equal to the size of the memory of the video card is reserved by the video card, and any data sent to those addresses actually ends up going to the video card. This design has many technical merits, but it makes the consumed memory addresses unavailable for use with physical memory.
Things only get more complex as we start including the operating system (in this case Windows) in to the equation. The above is actually handled by a combination of Windows and the BIOS, meanwhile Windows also needs some address space so that programs can communicate with the Windows kernel, for storing buffers, for storing memory tables, etc; all of which means we have lost even more address space. All of the above besides preventing us from addressing 4GB of physical memory are also the cause of the actual 2GB barrier that is the problem.
Quickly, there is one more pre-requisite piece of information: virtual address space. For a 32bit Windows application(Win32), each application has a full 4GB worth of private addressing space that it can use, which again is 32bits and a result of how a 32bit processor works. How the above exactly works is beyond the scope of this article, but it's sufficient to say that at some point virtual addresses get translated in to other addresses for mapping data between the application and physical memory or the swap file. The important thing to take from this is that each application has its own 4GB virtual address space, regardless of the hardware the computer contains or what applications are running. Now we may begin to understand the 2GB barrier.
Due to design reasons outside the scope of this article, Windows takes a pre-determined portion of each application's virtual address space and reserves it for itself. Windows uses its portion of the virtual address range for all of the address needs listed above. At the end of the day, and what really matters, is that in designing Windows Microsoft opted to split up the virtual address space of an application in half; 2GB goes to Windows (kernel space) and 2GB goes to the application (user space). Under normal circumstances this 2GB of space is all a 32bit application has to work with, this is the 2GB barrier and as we'll see is the cause of the problems with Supreme Commander.
It is also worth noting at this point that virtual address space is not directly correlated to physical memory size. Windows and any applications running under it may use up to all of their allocated virtual address space, with Windows simply swapping data between the hard drive and physical memory if the amount of physical memory needed is in excess of what's available - this is virtual memory, not to be confused with virtual address space. The only meaningful relation between virtual address space and physical memory is that the amount of physical memory an application can use can never be greater than its virtual address space. The user space must take up a larger portion of the virtual address space if an application is to use more than 2GB of physical memory.
Facebook
Twitter
RSS
69 Comments
View All Comments
instant - Saturday, July 21, 2007 - link
Could the writer please detail what, exactly, is wrong with XP-64bit edition?Having run it since it was released and never had a problem with it, I would be interested in knowing what problems I should have experienced.
BUL - Tuesday, July 17, 2007 - link
A few things I've found about /3GB in XP...1) In terms of "consumer" OS's, XP Pro is the only one to support it. (XP Home and W2K Pro DO NOT!) Vista has a different method, outlined in the article.
2) If you change boot.ini, make sure you add a "3GB" boot option to your operating systems, not just change the one entry to /3GB. If a new driver gets installed that doesn't like /3GB, you could be left without the ability to change boot.ini back. (I can't find any info on whether /3GB affects Safe Mode, however safe mode may run in "3GB" mode!) So, unless you have the ability to WRITE to NTFS partitions outside of Windows, you may be stuck if you don't. See http://www.gehrytechnologies.com/catia/catia/catia...">http://www.gehrytechnologies.com/catia/catia/catia... for how to do it...
Now, personally, I feel that a limitation like memory shows the "men from the boys" in terms of programmers. Windows and "endless memory" has allowed for bloatware for far too long and allowed for sloppy, inefficient programming... Just think back how many games & other programs could run on an XT with 640KB of RAM because the programmers wrote highly efficient code. (Lotus 1-2-3 for DOS was written primarily in assembler; Quattro Pro could open even larger spreadsheets than 1-2-3 because it utilized pseudo-virtual memory).
Now we've come full-circle into the world of Windows, and some of these programs now have to become more efficient. That's what programmers are paid to do...
Anorax - Monday, July 16, 2007 - link
On some of the larger maps in AW2 the game will occasional crash to desktop and leave an error window saying it has exceeded the 2GB memory space. Not that helpful but at least it tells you why it crashed.the Chase - Sunday, July 15, 2007 - link
Thank you so much for this article. I had a post awhile back in the forums asking for help on why in Vista I couldn't even run PR for bf2 unless I turned down the texture setting to Medium.Never figured it out though people here did offer some good ideas for fixes. After reading this article I knew this is what was going on. I searched on the Net and found out how to use Visual Studio C++ to modify the Bf2 executable. Problem solved! (I have the 64 bit version of Vista).
And to think I was ready(thinkeng about anyway) going to buy another 2 GB's of memory to try and cure the problem. Thanks again.
P.S. I also did the same fix for XP pro 64 and now PR runs much smoother than before in that OS also.
spookware - Friday, July 13, 2007 - link
Just wanted to mention that the description of how windows uses memory is correct for XP and previous versions but it is not quite how windows vista works.Specifically, vista does not automatically take the upper 2GB of adress space for the kernel any more. It instead grows the kernel adress space downard on demand. Allthough the associated switches (/3G) have the same prupose in vista what they are setting is actually the upper maximum for the kernel adress space.
Magumi - Friday, July 13, 2007 - link
I guess this means that if I want to buy a computer to last me at least three or four years, I need to get 64bit Vista and 8GB of RAM and hope that drivers and incompatibilities get resolved soon.Greyhead - Friday, July 13, 2007 - link
Ryan, great article. Some other posters mentioned the use of the /PAE on servers. I recently discovered that MS recommends NOT using the /3GB switch in conjunction with /PAE. I followed their advice on a large SQL server we have and saw immediate positive results. The problem with /PAE /3GB combination is that when the OS is limited to 1 GB, there is not enough room for the size of the heap needed to support the /PAE option! This can be viewed using performance monitor - selecting "memory" options and then viewing total PTEs available (Page Table Entries). There are MS articles that describe the minimum PTEs needed, and before I changed our server it was way under the minimum. We had stupid errors on the server - blue screens, "not enough memory" errors when transferring files to another machine. Once the change was made, these problems disappeared. 2003 server has a more tunable /3GB switch using the /USERVA switch. There are technet articles which provide guidance on it's usage.Keep up the great work -
-bill
redpriest_ - Friday, July 13, 2007 - link
binary is illegal.Kougar - Friday, July 13, 2007 - link
The moment I saw the title I was thinking of Supreme Commander. I particularly enjoy the insanely huge 8-player games, but it only took about 40 minutes before these would crash... oddly enough they did not always crash either in some situations, making the crashing appear random and only confusing my attempts to troubleshoot this game. It would have been quite appreciated that this issue would have at least been mentioned in the game's readme file, if nothing else.Having (very luckily) stumbled across MadBorris's thread I made the modifications to XP and SC has been running since. I have not run into any instability or issues with XP configured with the /3gb switch for what it is worth. Am I wrong in that users with video cards featuring smaller onboard memory sizes will have an "advantage" with this problem? There is a large difference between a 320mb GTS and 740MB GTX, or heaven forbid a 1GB HD 2900 card? And while on the subject does a dual-GPU configuration (and therefore dual VGA memory) make things even worse?
Ryan Smith - Friday, July 13, 2007 - link
Yes to the first question. To the second question I believe that's also a yes, but I don't have a system configured to test that theory.