What is the advantage of setting low Xmx for java heap space?

Question

We can set the maximal possible memory for a java heap space for our java VM with -Xmx, eg. -Xmx1g.

Why would one want to set -Xmx lower than some value if the priority is that java OutOfMemoryError heap space would not occur? Does VM manage the memory more efficiently if the maximal value is lower?

I constantly run into OutOfMemoryError and I have set -Xmx very high. The problem is that eventually I run out of physical memory too - so high Xmx alone is not sufficient. My current solution is to shut down my memory hungry applications which is very inconvenient as it slows down the development and testing.

Answer 1

The -Xms and -Xmx parameters define the minimum and maximum heap sizes, respectively.

Since GC occurs when the generations fill up, throughput is inversely proportional to the amount of the memory available.

By default, the JVM grows or shrinks the heap at each GC to try to keep the proportion of free space to the living objects at each collection within a specific range. This range is set as a percentage by the parameters -XX:MinHeapFreeRatio=minimum and -XX:MaxHeapFreeRatio=maximum; and the total size bounded by -Xms and -Xmx.

There is some guidelines for Java Heap Sizing available on the oracle site for glassfish tuning but should hold true for any JVM.

http://docs.oracle.com/cd/E18930_01/html/821-2431/abeic.html#abeij

A troubleshooting guide from IBM recommends aiming for an application specific heap usage of a minimum heap usage of around 40% and a maximum heap usage of around 70%

http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%2Fcom.ibm.java.doc.igaa%2F_1vg000139b8b453-11951f1e7ff-8000_1001.html

Does VM manage the memory more efficiently if the maximal value is lower?

Possibly, not over allocating the heap size objects will more correctly 'fill-out' to the correct memory generations since having a large heap size less GC will be performed meaning more objects sitting in the young generation for longer which provides faster garbage collection at the price of doubling the memory usage.

I would not see any additional overhead however being the cause of the your application running out of memory with a high maximum memory allocation as being the cause and its most likely there are large objects being stored in memory or there is a memory leak somewhere in the application that is the more pressing concern than heap management.

http://docs.oracle.com/javame/config/cdc/cdc-opt-impl/ojmeec/1.1/custom/html/tuning.htm

Answer 2

My main reason would be to insure that JVM memory usage fits in the available RAM. Say I had 3 tomcat instances running on machine with 8g of ram. I would probably set the mX to around 2g for each vm and allow 2g for os and other.

If the JVM is forced into swap it can give huge performance problems as the garbage collector navigates the object tree.

Answer 3

There is no need to set the -XMX-Parameter low. Just set it to the value you need for your application. But it's important to notice, that with higher -XMX-Value the GC-Time will increase and therefore it can happen that your application will not respond (depending on what collector you use). Out of personal experience 1G is not very high. I've JVMs with 4G, 8G or 16G and they are running fine

Answer 4

I believe if the memoru is larger then less frequently it needs to be GC-ed and there can be lots of garbage as GC can relax with that much of room. However, the GC has to work on more memory ,which in turn might make the GC slower.

The JVM heap size determines how often and how long the VM spends collecting garbage. An acceptable rate for garbage collection is application-specific and should be adjusted after analyzing the actual time and frequency of garbage collections. If you set a large heap size, full garbage collection is slower, but it occurs less frequently. If you set your heap size in accordance with your memory needs, full garbage collection is faster, but occurs more frequently.