Return back to the blog

-Xmx is hurting the usability of Java

Posted by Prashant Deva on August 11, 2011

How would it feel if every time you opened a program or a website it asked you how much memory it could use?

Or even worse it by itself decided some maximum memory value for you which is far lower than the amount of ram on your system. How would you then feel if that said program or website threw an error in your face complaining about memory, all this while you had more than enough ram on your system for it to use?

What Java does

Apparently that is exactly how Java programs behave or rather the JVM implementations compel java programs to behave. 

  1. Either you specify an -Xmx value and try to guess memory usage before hand, or 
  2. Depending on the vendor, version or implementation the JVM will choose its own maximum heap size (which is almost always lower than the total ram on your machine).

What it should Do

Now I am sure there are good technical reasons why this is the case. However I will cite the age old programming quote:

First make it correct, then make it fast.

In this case going Out Of Memory on a system which does have enough memory is plain incorrect. Any program on a system can due to unforeseen circumstances might temporarily require more memory than its user thought it would. It could be that disk IO became slow or there were suddenly a traffic spike for a few minutes, etc. Operating Systems found a way around this a long time ago using virtual memory and disk swapping. Sure swapping causes your program to go slow but it doesn’t outright crash it.

I have 24gb of ram on my machine (since ram is super cheap nowdays). I should never see an OutOfMemoryException. Yet time and again I see it pop up in Java programs, even when they were using a mere fraction of my 24 gigs of ram.

Real World Experience

We have so many cases of people using Chronon on 64 bit machines and getting Out Of Memory Exceptions.  We keep getting queries like “but my machine has 4 gigs of ram” and we always have to say “but did you allow the jvm to use it? whats your -Xmx value?“. 

Since the performance of Chronon is greatly impacted by memory, with our Time Traveling Debugger Eclipse plugin, during installation we bump up the -Xmx value of Eclipse. Although all this does is allow Eclipse to use the extra memory if needed, due to the common misconception out there, people think just by setting a higher -Xmx value Eclipse is magically using more memory than before.


All said and done, I think the need to specify a max heap or randomly choosing a heap size less than the system memory highly impacts the usability of Java programs in a 64 bit world, and leads to confusion with people who get Out Of Memory errors even though they have plenty of memory. The performance gains are not worth the errors and confusion.



Tagged 11 Comments |

11 thoughts on “-Xmx is hurting the usability of Java

  1. But the other point of view is "How would you feel if a seemingly innocent Java app consumed all 24Gig of RAM, grinding the rest of your computer to a halt?"I’m guessing there is some optimisation that they can do better when they know the max limits of the memory space. Yeah, the defaults might be a bit low these days, and perhaps a percentage is better than an absolute value, but given how much of a memory hog I’ve found many Java apps to be then I think I like the cap!

  2. The Excelsior JET JVM lets you specify a special value of 0 for heap size, meaning "adaptive", i.e. it will monitor the amount of _available physical memory_ and enforce GC if it is low. You may also choose whether to page the heap out to disk or throw an OOM when your system runs our of physical memory, and control how often GC is invoked, e.g. to prevent long pauses:

  3. I’m not sure then why when I specify -Xmx2g my JVM eats up 12 gig of memory. I’ve never seen a JVM that seems to honor -Xmx. I’ve never been able to find any info as to why this occurs.

  4. Even odder – I’ve never seen it *not* happen. For years. Multiple systems, multiple JVMs. I just assumed it was broken.

  5. Java has never been much of a success story on the client for reasons like this (apart from Android). Java’s huge success has been on the server where admins don’t mind changing the -Xmx value. I maintain a memory intensive Java client application. We have a script that first fires up a JVM, and determines max heap size (via OperatingSystemMXBean) which is in and of itself a kludge because not all JVMs support determining max heap size so you gotta use the getTotalPhysicalMemorySize method via reflection. This value is passed back to the script (there goes write once run everywhere) and a percentage of that value is used to set the -Xmx value in the "real" application. Ohh and if you are running on a 32bit OS you cannot go higher than 1.5 GBs. Got all that?

  6. @JulienChastang: many of our customers develop desktop apps in Java and our adaptive heap size feature has been working well for them.Our memory manager also releases memory to the OS if it has not been re-requested for some time, which only some of the HotSpot GCs do:

Comments are closed.