A Messy Transition: Practical Problems With 32bit Addressing In Windows
by Ryan Smith on July 12, 2007 12:00 PM EST- Posted in
- Software
As it turns out, it's possible and actually quite easy to move the 2GB barrier by increasing the size of the user space, but at the cost of reducing the size of the kernel space. Under Windows XP, this is the fabled "/3gb" switch for boot.ini, and for Windows Vista it's the "IncreaseUserVa" option in BCDedit. By using these options applications can use more than 2GB of virtual address space (generally up to 3GB), and ideally this would be the end of the article.
Unfortunately this is not the case as there are problems on both the application and kernel side of things. On the application side, a common poor programming practice has been to always assume that an application will only be dealing with 2GB of user space; code that makes this assumption will likely error if more than 2GB of user space is actually available. This is avoidable by following proper programming practices, but as a safety precaution even with additional virtual address space allocated to user space Windows still defaults to limiting an application to 2GB. Only finally, if an application indicates to Windows that it is capable of handling more than 2GB, via the "/LARGEADDRESSAWARE" flag, may it have access to any space above 2GB.
As for the kernel, having had up to half of its space taken away must now find a way to live in a smaller space. The (in)ability of any specific system/Windows configuration to deal with this is why the 3gb switch is considered dangerous, seldom recommended, and just generally a bad idea. The biggest culprit here is drivers that run in kernel space. Like applications, they may assume that there's an entire 2GB of address space to work with, except unlike applications this space gets smaller instead of bigger.
Windows' own memory needs can also cause problems with the reduced kernel space. As we mentioned before, space is required for the kernel to do a multitude of things, if a lot of space is required - video cards with a lot of memory are a particular offender here - then everything needing space may not fit in the kernel space. Because there are no strong safeguards against these conditions it may cause a failure to boot or system instability, especially if the culprit is a driver that is well enough behaved to boot. Many modern drivers from hardware vendors that deal with enterprise-level hardware are capable of handling this, many more consumer hardware drivers are not. Stability concerns are the number one reason that breaking the 2GB barrier on a 32bit version of Windows is not recommended.
There is also a second concern however: performance. While an individual application may benefit from more user space in which to work, the kernel now has less space to cache data (as non-obvious as this may seem given all the addresses are virtual) and this can in theory hurt performance. This condition is something we will take a look at in a bit.
Facebook
Twitter
RSS
69 Comments
View All Comments
nullpointerus - Thursday, July 12, 2007 - link
64bit versions of Windows(i.e. XP and Vista) do not suffer from the traditional 2GB barrier, as all the kernel mode addressing is usually moved to well above the confines of the limited 32bit addressing area. As such, these versions of Windows don't need to have their space allocations adjusted for an application to gain access to more addressing space, bypassing the instability and any possible performance problems that occurs as a result of making this adjustment.I used 64-bit Vista for a while but just couldn't deal with the BSOD's and other wierd behavior that would happen with 4 GB RAM installed and the BIOS memory hole option set. For example, the nVidia SATA drivers (3 updates on Windows Update alone) for my board would BSOD on every boot when the BIOS memory hole option was enabled, and the PVR-150's driver would randomly corrupt itself and turn into a green/garbled slideshow:
http://www.hauppauge.co.uk/board/showthread.php?t=...">http://www.hauppauge.co.uk/board/showthread.php?t=...
I wish the 64-bit driver developers would get off their butts and fix this stuff.
gersson - Thursday, July 12, 2007 - link
Large Address Aware Statusit says, "STALKER: Oblivion Lost"
Ryan Smith - Thursday, July 12, 2007 - link
I'm not sure I see what the problem is. Could you go in to more detail?gersson - Thursday, July 12, 2007 - link
You meant to place 'Stalker' cos there is already an entry for oblivion and 'lost' (I assume you mean 'lost planet')Read like this:
Observe first line:
STALKER: Oblivion Lost Yes
Lost Planet No
Company of Heroes Yes
Supreme Commander No
Enemy Territory: Quake Wars Yes
Battlefield 2142 No
Call of Juarez DX10 BM No
World of Warcraft No
The Elder Scrolls IV: Oblivion No
Photoshop CS3 Yes
Dreamweaver CS3 No
DigitalFreak - Thursday, July 12, 2007 - link
No. Stalker had the working title of Stalker: Oblivion Lost...gersson - Thursday, July 12, 2007 - link
hmm ok, didn't know that -- but you can see how I had arrived @ my conclusion :-PThe Boston Dangler - Thursday, July 12, 2007 - link
the game was released as STALKER: Shadow of Chernobyl. no biggieRyan Smith - Thursday, July 12, 2007 - link
Fixed. I keep forgetting they changed the name.grant2 - Thursday, July 12, 2007 - link
So this game will crash reproducably when using a large map, with many players, and many units.And GPG released it like this? Either their QA department is rather incompetent, or management were buffoons to ignore such an obvious error.
Very disapointing!
EODetroit - Thursday, July 12, 2007 - link
I've been hoping Anandtech would take memory issues more seriously for a while now, glad you're getting your teeth into it for real now!"Unfortunately Windows Vista reverted to a non-accelerated desktop at this point, preventing us from capturing a screenshot of the exact memory readouts or the error message."
Use a camera!