32bit Windows Memory and Java
Understanding 32bit process limitations in Windows is complex. The following is a quick run down of basics, followed by a quick explanation of JRockit (and why it rocks!).
Physical Address Extension
So as you can see from above, Physical Address Extension allows a 32bit OS to address up to 64GB of RAM. 32bit Windows can in fact have up to 64GB of RAM depending on the version. See the following to learn about the memory limits of each version of Windows and PAE:
In short, if you run 32bit Server 2003 Enterprise you can put up to 64 GB of RAM in your machine (provided your hardware has PAE). From a process perspective, PAE is unimportant.
Process Address Space (No /3GB switch)
Now we talking about how much memory a 32bit process can use in Windows. By default without modifications the theoretical limit is 2GB. In practice the limit is usually around 1.5GB.
This is because for a 32bit process Windows cuts the Process Address Space in half. Half goes to Kernal Memory (which a user process cannot use) and the other half goes to user mode (which you can use). It doesn't matter how much RAM is in the box, a 32bit process can only use 2GB of RAM. See below for more info:
Process Address Space (With /3GB switch)
When you use the /3GB in the boot.ini what this does is it decreases the Kernal mode memory and increases the user mode memory. But there is a catch, the program must be compiled/linked using the /LARGEADDRESSAWARE switch.
See the following under the Application Changes section:
Address Windowing Extensions
The final thing is Address Windowing Extensions. This when a program is written to use more memory that what is in the Process Address Space. I think Exchange, and SQL have this ability. Below is more information:
Some hopefully that helps to focus what's going on with 32bit processes in Windows. If your into Java hopefully know your asking yourself is the JRE compiled with the /LARGEADDRESSAWARE switch?
Finding the answer to that has proven very difficult, but the answer is a disappointing no.
This is the best answer I could find. See:
This is the important part:
So what does the /3GB switch do for Java then?
The /3GB switch does enable the Java heap to grow a bit from a
practical max of about 1.5 GB up to 1.7 GB or maybe even 1.8 GB. If
you are already struggling to fit everything into your Java heap, the /3GB
switch is not going to be of much help.
The key advantage lies in the extra space available for threads (stack
space), and native code (either for JIT’d code or application
Below is another explanation:
JRocket is the Oracle version of the JRE. It is compiled with the /3GB switch. In addition it doesn't need a continues Process Address Space.
Usually when the Sun JRE/JDK asks Windows for a ton of memory, say like 1.5GB. What it really says to Windows is I need 1.5GB of continues memory. This can be a hard order to fill for the OS depending on what it is doing at the time. JRocket doesn't require the memory be continues which is great!
More information about JRocket can be found under the following links:
Just to illustrate that drastic difference you can get between the Sun JRE/JDK and JRocket below are some screen shots from a JBOSS server. The box has 5GB of RAM and the /3GB switch enabled. Using the standard JRE I can't start JBOSS with more than 1536MB of memory. Using JRocket I can start it with a whopping 2560MB of memory.
With Sun JDK
JRocket kicks ass! Not only can it use more memory than the Sun JRE it's also optimized for speed!