The Mystery of the Maximal -Xmx Settings, Ergonomics and Tuning

From time to time, especially developers working with windows, run into problems with JVMs maximum heap. Although in theory the maximum heap on 32bit OS should be 4 GB, it is actually on windows less than a half of the theoretical setting. The actual number is around 1.4GB, it is hard to reach 1.5GB. I found several resources, which point to the causes of this behavior. This older entry, explains the reasons (windows systems reserve some memory for "private use", which is no more available for applications). It contains some links to MSDN as well. This bug report, explains the behavior, as a problem in the JDK's dll. It mentions also, that other JVMs (like JRockit) are able to handle slightly more maximum heap. However on my Vista 32bit machine (3GB RAM), the highest heap I was able to set up was 1626m (it isn't able to start with 1628m...sometimes with 1629m it varies,) with Sun's JVM. I tested it with the SwingSet, the Swing demo application: java -Xmx1620m -jar SwingSet2.jar

If you are interested in GC/JVM tuning, this whitepaper is a good resource. It explains the default settings, tuning ideas and ergonomics in great detail.


NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Airport MUC workshops: Web (SPA, PWAs, Offline, Desktop, Mobile) Applications Essentials and Effective Web Applications. No migrations. #usetheplatform

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

Hi,

I haven't read through all the papers you linked, but the reason why you can't allocate very big heaps is that the whole heap has to be allocated in one huge chunk of memory... And win32 loads some dll in the 2GB area..

thats why allocations/deallocations are so damn fast in java and in other languages on top of the VM. It is actually no real allocation it is more a "drop the pointer" mechanism on known defragmented, pre-nulled space.

Posted by Michael Bien on February 14, 2008 at 05:11 PM CET #

Yes, but it is only a Windows issue...

Posted by Adam Bien on February 14, 2008 at 05:28 PM CET #

>Yes, but it is only a Windows issue...
I wouldn't say that. It is _especially a win32 issue because win32 allocates (because of unknown reasons) memory in the 2GB area of your RAM. Thats why you get the 1.6 GIG of Heap max.

=>Your biggest chunk of RAM is somewhere between the dll at 2Gig and "the rest of win32".

I am not sure but I bet if you would write a program in C which allocates 1 byte each 10MB it would be impossible to boot Sun's JVM in this environment (on linux too).

here another link on that topic:
http://forums.java.net/jive/thread.jspa?threadID=36441&tstart=0

Posted by Michael Bien on February 14, 2008 at 06:54 PM CET #

>I am not sure but I bet...
ok I lost the bet :/ I would get 2 of 2GB on linux if I would want to.

(but the story with the win32 system files at 2GB address space is still true and the reason for the max mem issue on win32 ;) )

Posted by Michael Bien on February 14, 2008 at 07:16 PM CET #

hi there,

I was experimenting a while back on this. I noticed that there is a switch in the file C:\BOOT.INI which can enable more than 2 GB of heap for user applications. But that is supposing that you have more than 3 GB RAM.

Yes, I got more RAM from jRockit (but that is fragmented).

BR,
~A

Posted by anjan bacchu on February 14, 2008 at 09:31 PM CET #

Just to note that current JRockit versions do not require the heap to be contiguous and can thus use space above where the windows system files are loaded.

http://dev2dev.bea.com/blog/hstahl/archive/2005/12/how_to_get_almo.html

Regards,
/Staffan

Posted by Staffan Larsen on February 15, 2008 at 04:07 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License