JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 036 contents

Help, I'm getting an OutOfMemoryError but I've tuned as much as I can.

There are three possible causes for an OutOfMemoryError. The first is that the JVM has a real memory leak, caused by a bug in the internal implementation of the JVM heap management. This is extremely unlikely. All JVMs are tested very strenuously for this, and it would be the absolute top priority bug if anyone found such a bug. So you can pretty much eliminate this possibility.

The second possible cause of an OutOfMemoryError is that you simply haven't got enough memory available for the workings of your application. There are two possible solutions to this situation, either increase the available JVM heap size, or decrease the amount of memory your application needs. Increasing the available JVM heap size is simply done with the -Xmx parameter to the JVM. If you still have the memory problem because you have already increased this parameter as much as possible (up to available RAM, don't exceed real system memory or your application will page and crawl to a halt), then you need to reduce the amount of memory being used by your application. Reducing application memory may be simple, you may just be allowing some collections to be too big, for example using many large buffers. Or it can be complex, requiring you to reimplement some classes, or even redesign the application.

Reader James Stauffer has pointed out that with some JVMs (e.g. the Sun JVMs), there is also a "Perm" space which holds JVM structures and class objects. If you are using a very large number of classes, it is possible to run out of space in "Perm" space, and you may need to increase the size of that space, e.g. with the Sun JVM using the -XX:PermSize and -XX:MaxPermSize options.

The third possible cause of an OutOfMemoryError is the most common, unintentional object retention. You are hanging on to objects without realizing it and this is causing your heap to grow and grow until you have nothing spare.

Dealing with an OutOfMemoryError:

• Is it an internal JVM bug? Extremely unlikely. Highest priority JVM bug if true (so how come no one else has found it yet?)
• Not enough memory for actual application needs? Two options:
  • Increase the maximum heap size with -Xmx parameter (or Perm space size with -XX:MaxPermSize); or
  • Decrease the amount of memory needed by using smaller collections/caches/tables/objects/..., i.e. by tuning object sizes, by redesign, and by reimplementation
• Unintentional object retention? Find the root object holding on to the unintentionally retained objects, and change it to release those objects. A generic procedure for doing this is outlined in this IBM developerworks article. A summary of the procedure is
  • Wait until the application has reached the steady state, where you would expect most new objects are temporary objects that can be garbage collected; typically this is after all the application initializations have finished.
  • Force a garbage collection, and take an object snapshot of the heap.
  • Do whatever work it is that is causing unintentionally retained objects.
  • Force another garbage collection and then take a second object snapshot of the heap.
  • Compare the two snapshots to see which objects have increased in number from the first snapshot to the next. Because you forced garbage collections before the snapshots, the objects left should all be objects referenced by the application, and comparing the two snapshots should identify exactly those newly created objects that are being retained by the application.
  • Using your knowledge of the application, determine from the snapshot comparison which of the objects are being unintentionally retained.
  • Track back-references to find which objects are referencing the unintentionally retained objects, until you reach the root object that is causing the problem.

The JavaPerformanceTuning.com team

Back to newsletter 036 contents