Diagnosing OutOfMemoryError exceptions in Metronome Garbage Collector can be more complex than in a standard JVM because of the periodic nature of the garbage collector.
In general, a realtime application requires approximately 20% more heap space than a standard Java™ application.
The Java backtrace shown on the console output, and also available in the Javadump, indicates where in the Java application the OutOfMemoryError occurred. The JVM memory management component issues a tracepoint that gives the size, class block address, and memory space name of the failing allocation. This tracepoint can be found in the snap dump:
<< lines omitted... >> 09:42:17.563258000 *0xf2888e00 j9mm.101 Event J9AllocateIndexableObject() returning NULL! 80 bytes requested for object of class 0xf1632d80 from memory space 'Metronome' id=0xf288b584
The tracepoint ID and data fields might vary from that shown, depending on the type of object being allocated. In this example, the tracepoint shows that the allocation failure occurred when the application attempted to allocate a 33.6 MB object of type class 0x81312d8 in the Metronome heap, memory segment id=0x809c5f0.
NULL ------------------------------------------------------------------------ 0SECTION MEMINFO subcomponent dump routine NULL ================================= NULL 1STMEMTYPE Object Memory NULL region start end size name 1STHEAP 0xF288B584 0xF2A1C000 0xF6A1C000 0x04000000 Default NULL 1STMEMUSAGE Total memory available: 67108864 (0x04000000) 1STMEMUSAGE Total memory in use: 66676824 (0x03F96858) 1STMEMUSAGE Total memory free: 00432040 (0x000697A8) << lines removed for clarity >>
NULL ------------------------------------------------------------------------ 0SECTION CLASSES subcomponent dump routine NULL ================================= << lines omitted... >> 1CLTEXTCLLOD ClassLoader loaded classes 2CLTEXTCLLOAD Loader *System*(0xF182BB80) << lines omitted... >> 3CLTEXTCLASS [C(0xF1632D80)
Information in the Javadump confirms that the attempted allocation was for a character array, in the normal heap (ID=0xF288B584) and that the total allocated size of the heap, indicated by the appropriate 1STHEAP line, is 67108864 decimal bytes or 0x04000000 hex bytes, or 64 MB.
In this example, the failing allocation is large in relation to the total heap size. If your application is expected to create 33 MB objects, the next step is to increase the size of the heap, using the -Xmx option.
It is more common for the failing allocation to be small in relation to total heap size. This is because of previous allocations filling up the heap. In these cases, the next step is to use the Heapdump to investigate the amount of memory allocated to existing objects.
The Heapdump is a compressed binary file containing a list of all objects with their object class, size, and references. Analyze the Heapdump using the Memory Dump Diagnostics for Java tool (MDD4J), which is available for download from the IBM Support Assistant (ISA).
Using MDD4J, you can load a Heapdump and locate tree structures of objects that are suspected of consuming large amounts of heap space. The tool provides various views for objects on the heap, Figure 1 shows a view created by MDD4J detailing likely leak suspects, and giving the top five objects and packages contributing to the heap size.