It was my understanding that it's per process, not the total processes. But according to Large memory support is available in Windows Server 2003 and in Windows 2000 (KB283037):

Typically, a process running under Windows 2000 or Windows Server 2003 can access up to 2 GB of memory address space (assuming the /3GB switch was not used) with some of the memory being physical memory and some being virtual memory. The more programs (and, therefore, more processes) that run, the more memory you commit up to the full 2 GB of address space.

That to me says the more programs you run the more chance you will hit the 2GB address space limit i.e. Program A uses 500MB, Program B uses 1GB, so you've only got 500MB of address space for the rest of your programs.

However an MSDN article http://msdn.microsoft.com/en-us/library/ms189334.aspx refers to this as Process Address Space and to me implies that each application gets its own address space, be it 2GB or 3GB, depending what switch is being used in the boot.ini.

So is it per process or total process? And is the knowledge base article wrong (or badly worded)?

(Please note I'm talking about 32-bit systems only)

  • Each process gets its own process space. Even if you have 512M (or less) of RAM, each process gets 2G of space to play with. What happens when it uses it all? Well... – Bill Weiss Aug 27 '09 at 18:03
  • So, if you use /3G, you get 3G per process. – Bill Weiss Aug 27 '09 at 18:04

It's virtual address space per process, as per the MSDN article, and the superb series of articles on this written by Raymond Chen and archived at his blog.

Here is his index page for this series of articles - very well worth a read if you're dealing with large memory support as a senior system admin or a developer.

  • 1
    ...and if you don't fully understand it - you don't need it. The instances when it's actually beneficial should be extremely rare... – Oskar Duveborn Aug 27 '09 at 17:33
  • So is the knowledge base article wrong or badly worded? – fenster Aug 27 '09 at 17:35
  • fenster, I'll go with wrong because it's badly worded - I think I can see what they're driving at but they've confused things to the point where it's broken. It sounds like the article got its wires crossed between physical memory, the effects of the PAE switch, the effects of the 3GB switch and good old virtual memory. KBase articles aren't always right, and even when they are they aren't always clear. – Rob Moir Aug 27 '09 at 19:04

It only increases the address space for programs that are compiled with a magic bit that can optionally look for this extra space.

This magic bit is for "Large Address Aware" support.

Most Microsoft programs (I believe) have this bit enabled by default.

There is a tool available on the internet, LaaTIDO, that enables this bit. I've used this tool to enable Large Address support for Tomcat & Sun's JDK running on windows.


The problem with this flag is that some programmers are unaware that a memory location can be above the 2 GB limit, which can cause some nasty bugs in the application. And let me explain why...

A pointer to an address in RAM is similar to a 32-bit signed integer in certain languages. Signed means that it can be positive or negative. Now, to check if a pointer is assigned or not, you check if it's equal to NULL/nil or not. If it's not null, it's assigned to something. Some programmers check for this by checking if the address is greater than null, thus they're forgetting about the possibility that addresses might be negative. Since a negative pointer is smaller than null, the system will think it's unassigned and thus re-assign a new value to it, losing it's current value and leaking memory.

Fortunately, most programmers learned to check if it's equal or not equal instead of greater-than null. In that case, the application would have no problem using up to 3 GB.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.