Originally posted in December 2005 on http://dev2dev.bea.com/blogs/hstahl, reposted on request with a few minor updates. I find it amazing that the very useful "non-contiguous heap" feature described here is still unique to JRockit after 2.5 years...
As you may be aware, the maximum heap size on Window using JRockit - or for that matter any JVM we are aware of - has been limited to slightly below 2 GB. There have been two reasons for this. One is that the maximum process size on Windows has been limited to 2 GB, though this can be worked around by using the /3GB kernel switch. The second is that JVMs have required a contiguous memory space for the Java heap for efficiency reasons, which causes the maximum Java heap size to be limited by DLLs loaded into the process address space.
For more information and previous discussion on this topic see:
Microsoft PAE & /3GB docs
JRockit docs
Sun blog
With the soon to be released JRockit 5.0 R26 (update: released in 2006) this barrier is broken! By introducing support for split heaps, we have been able to significantly increase the Java heap size on Windows.
Windows 2003/XP or later using the /3GB switch (32-bit OS)
1.85 GB - JRockit versions prior to 2006
2.85 GB - JRockit versions post 2006
Windows 2003/XP x64 Edition with a 32-bit JVM (64-bit OS)
2.05 GB - JRockit versions prior to 2006
3.85 GB - JRockit versions post 2006
How do I enable this feature?
32-bit Windows
1. Add the /3GB switch to your boot.ini file as described here
2. Install and run a recent version of JRockit specifying a large -Xmx
64-bit Windows
1. Install and run the 32-bit version of JRockit specifying a large -Xmx
How large is the performance overhead?
Zero!
What if I need an even larger heap?
Use one of the many 64-bit version of JRockit.
Are there any drawbacks?
You still need to make sure there is enough memory for JVM internals, compiled code and any native libraries you will be using. If JRockit exits with an out of memory error in native code, try decreasing the heap size slightly.
