Getting OutOfMemoryError when I'm at less than 10% of max.

Question

Certain users are seeing this error randomly when they start the application (happens about 1 out of 10 times they start the app). The entire Java exe is using around 90MB according to Task Manager; the max is set to 1024MB. I am looking for any clues on how to start debugging/fixing the issue:
Exception:
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
     at java.awt.image.DataBufferInt.<init>(Unknown Source)
     at java.awt.image.Raster.createPackedRaster(Unknown Source)
     at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
     at sun.awt.image.SunVolatileImage.getBackupImage(Unknown Source)
     at sun.awt.image.VolatileSurfaceManager.getBackupSurface(Unknown Source)
     at sun.awt.image.VolatileSurfaceManager.initialize(Unknown Source)
     at sun.awt.image.SunVolatileImage.<init>(Unknown Source)
     at sun.awt.image.SunVolatileImage.<init>(Unknown Source)
     at sun.awt.image.SunVolatileImage.<init>(Unknown Source)
     at sun.awt.image.SunVolatileImage.<init>(Unknown Source)
     at sun.awt.windows.WComponentPeer.createVolatileImage(Unknown Source)
     at java.awt.Component.createVolatileImage(Unknown Source)
     at java.awt.Component$BltBufferStrategy.createBackBuffers(Unknown Source)
     at java.awt.Component$BltBufferStrategy.revalidate(Unknown Source)
     at java.awt.Component$BltBufferStrategy.revalidate(Unknown Source)
     at java.awt.Component$BltBufferStrategy.getDrawGraphics(Unknown Source)
     at javax.swing.BufferStrategyPaintManager.prepare(Unknown Source)
     at javax.swing.BufferStrategyPaintManager.paint(Unknown Source)
     at javax.swing.RepaintManager.paint(Unknown Source)
     at javax.swing.JComponent.paint(Unknown Source)
     at java.awt.GraphicsCallback$PaintCallback.run(Unknown Source)
     at sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source)
     at sun.awt.SunGraphicsCallback.runComponents(Unknown Source)
     at java.awt.Container.paint(Unknown Source)
     at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
     at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
     at javax.swing.RepaintManager.seqPaintDirtyRegions(Unknown Source)
     at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source)
     at java.awt.event.InvocationEvent.dispatch(Unknown Source)
     at java.awt.EventQueue.dispatchEvent(Unknown Source)
     at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
     at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
GC log:
1.473: [GC 13184K->2704K(63936K), 0.0078083 secs]
2.142: [GC 15540K->6170K(63936K), 0.0117804 secs]
2.205: [GC 19354K->7206K(63936K), 0.0045008 secs]
2.273: [Full GC 13790K->7052K(63936K), 0.0578393 secs]
10.497: [GC 20236K->8518K(63936K), 0.0021190 secs]
11.517: [GC 21702K->8456K(63936K), 0.0023419 secs]
11.520: [Full GC 8456K->7794K(63936K), 0.0690542 secs]
11.604: [Full GC 7794K->4384K(997824K), 0.0601337 secs]
Client is running Java 6u14 on Windows XP SP3, with these arguments:
-Xms64m
-Xmx1024m
-Xloggc:{filename removed}
-Djava.ext.dirs={dirs removed}
-XX:+UseConcMarkSweepGC
-Dsun.java2d.d3d=false
-Dsun.java2d.ddoffscreen=false
-Dcom.sun.management.jmxremote
Any ideas?
Thanks,
Thomas

Answer 1

Maybe using a different collector (e.g., -XX:+UseSerialGC instead of -XX:+UseConcMarkSweepGC) would be diagnostic, even if it didn't give you as short GC pauses.
Maybe getting a heap dump on the OutOfMemoryError (-XX:+HeapDumpOnOutOfMemoryError, and see [http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/clopts.html|http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/clopts.html] for how to use it) and looking to see what's in the heap? There are also tools (jmap, etc.) for getting heap dumps at times of your choosing.
Figure out what caused the heap to grow from 63936KB at 11.520 to 997824K at 11.604. It looks like you barely survived that collection, so it's not unthinkable that something like that could push you over your 1024MB limit. I can't imagine what it is, though, since the collection itself says there was almost nothing (7794K) in the heap before the collection started. E.g., are you failing to allocate a single 1GB object? Failing to allocate would cause an OutOfMemoryError (duh!), but leave no traces in the heap (because we failed to allocate the object). Maybe using -XX:+PrintGCDetails would say more about the sizes of things in the heap from the sizes of the generations. Maybe -XX:+PrintHeapAtGC would tell you something about the sizes of the survivor spaces, permanent generation, etc. that would be instructive.