Adam Bien's Weblog

Thursday Feb 14, 2008

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.


[my tweets]  Rss My book: Real World Java EE - Rethinking Best Practices

Kommentare:

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.

Gesendet von Michael Bien am February 14, 2008 at 04:11 PM CET #

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

Gesendet von Adam Bien am February 14, 2008 at 04: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

Gesendet von Michael Bien am February 14, 2008 at 05: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 ;) )

Gesendet von Michael Bien am February 14, 2008 at 06: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

Gesendet von anjan bacchu am February 14, 2008 at 08: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

Gesendet von Staffan Larsen am February 15, 2008 at 03:07 PM CET #

Senden Sie einen Kommentar:
  • HTML Syntax: Ausgeschaltet
Interviews/About
My Recent Book
Java One 2009
CommunityOne East N.Y.C
JavaONE 2008 Interview
Search
...the last 150 posts
...the last 10 comments
greenfire.dev.java.net
Links
my.netbeans.org
Visitors
License