Breaking news, industry blogs and live commentary

IBM News on Ulitzer

Subscribe to IBM News on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get IBM News on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


IBM Journal Authors: Yeshim Deniz, Lana Tannir, Liz McMillan, APM Blog, Janakiram MSV

Related Topics: Java EE Journal, IBM Journal, Java Developer Magazine

Article

Unveiling the java.lang.Out OfMemoryError

And dissecting Java heap dumps

Simulation of a Memory Leak in a Static Variable
We can build a class with a static variable (see Listing 2c). We can build ClassVariableTest to instantiate ClassVariableExample (see Listing 2d)

Let's run ClassVariableTest with 1024 Mbytes of THE maximum Java heap size. No wonder, we got java.lang.OutOfMemoryError and a Java heap dump. We can open the Java heap dump with the IBM HeapAnalyzer, which would lead you to a leak suspect right away (see Figure 12).

This heap dump was taken from a JVM with a Java maximum heap size of 1024 Mbytes. The used heap size is 1,072,617,312 bytes (1023MBytes), which is pretty close to 1024 Mbytes. So the Java heap got almost exhausted. Let's find out which objects are using most of the Java heap.

The first class, com/ibm/jvm/ExtendedSystem, has references to other objects and the sum of the sizes of all the objects referenced from the class and its descendants is 1,070,471,976 bytes. 757 is the number of root objects.

The array of java/lang/Object is a leak suspect. 1,070,442,368 is the TotalSize. [10,256] is the Size of the object. 2,007 is the number of children. array of java/lang/Object is the name of the object. 0x101f8ed0 is the address of the object.

Let's climb up the tree. The java/util/Vector contains the array of the java/lang/Object. The class ClassVariableExample has a reference to the java/lang/Vector. With this information, we can tell the java/util/Vector came from the class ClassVariableExample.

TotalSize (TotalSize/HeapSize%) [ObjectSize] NumberOfChildObject(757) ObjectName Address
1,070,471,976 (99%) [312] 11 class com/ibm/jvm/ExtendedSystem 0x2d8d68
1,070,449,016 (99%) [312] 6 class java/lang/ClassLoader 0x2d29a8
1,070,446,664 (99%) [128] 15 sun/misc/Launcher$AppClassLoader 0x101eb7b0
1,070,443,112 (99%) [32] 1 java/util/Vector 0x102537b8
1,070,443,080 (99%) [56] 4 array of java/lang/Object 0x10253780
1,070,442,712 (99%) [312] 1 class ClassVariableExample 0x101defb0
1,070,442,400 (99%) [32] 1 java/util/Vector 0x10270d10
1,070,442,368 (99%) [10,256] 2,007 array of java/lang/Object 0x101f8ed0
800,016 (0%) [800,016] 0 long[] 0x11cefae8
800,016 (0%) [800,016] 0 long[] 0x2c831f68
...

Let's expand an array of java/lang/Object to find what are referenced from the array of java/lang/Object (see Figure 13).

We can see there are arrays of long[]. There are 2,007 entries in the array. The array of java/lang/Object is referenced from java/util/Vector because java/util/Vector is implemented with an array of java/lang/Object. java/util/Vector is referenced from the class ClassVariableExample. We found a leak suspect and class where the suspect is located.

We've accomplished our mission but it wouldn't hurt to explore the Java heap dump further. Let's find out how many long[] we have in this Java heap dump by selecting "List same type" menu from the context popup menu (see Figure 14). There are 671 of long[] in the Java heap dump and there are 2,007 objects referenced from an array of java/lang/Object. So there are other types of objects referenced from the array of java/lang/Object (see Figure 15). Let's display all the objects referenced from the array of java/lang/Object by selecting the "List children" menu from the context popup menu (see Figure 16).

We can see lots of long[] in Figure 17. If we scroll down a little, we can find float[] and int[] in Figure 18. How many of float[], int[] and long[] do we have in the Java heap dump? We can find it out by selecting "Types List" menu (see Figure 19).

Types List View provides an aggregated list of all classes and arrays sorted by size. We can see that long[], int[], and float[] are responsible for most of the Java heap space in the Java heap dump (see Table 3). We've shown that we can find memory leaks in static variables (see Figure 20). Can we also find memory leaks from instance variables and which object is responsible for it?

Simulation of Memory Leak in a Java Instance Variable
We can write an application to simulate a memory leak in an instance variable (see Listing 2e). After running InstanceVariableTest we can bring up the Java heap dump:

TotalSize (TotalSize/HeapSize%) [ObjectSize] NumberOfChildObject(502) ObjectName Address
51,202,240 (98%) [16] 1 InstanceVariableExample 0x14e2278
51,202,224 (98%) [32] 1 java/util/Vector 0x14e2288
51,202,192 (98%) [656] 96 array of [Ljava/lang/Object; 0x3db47a8
800,016 (1%) [800,016] 0 long[] 0x2300568
800,016 (1%) [800,016] 0 long[] 0x354ffa8
...

An array of the object is a leak suspect. It's referenced from java/util/Vector, which is referenced from an object, InstanceVariableExample. We can definitely find out which object is responsible for instance variables from the Java heap dump (see Figure 21).

Simulation of a Memory Leak in a Java Local Variable
We can chase down static variable and instance variable. What about local variables? Let's build an application to simulate memory leak in local variable (see Listing 3). We can run LocalVariableTest and analyze the Java heap dump.

TotalSize (TotalSize/HeapSize%) [ObjectSize] NumberOfChildObject(503) ObjectName Address
51,202,224 (98%) [32] 1 java/util/Vector 0x14b2208
51,202,192 (98%) [656] 96 array of [Ljava/lang/Object; 0x3d84728
800,016 (1%) [800,016] 0 long[] 0x22d04e8
...

We found a memory leak at the array of the Object, which is referenced from java/util/Vector. But there's no information about who created the java/util/Vector. Unfortunately we can't figure out who created the local variable from the Java heap dump alone. Do you remember HeapExhaustionSimulator that we used to simulate Java heap exhaustion? We couldn't find out who created the vector in the Java heap dump either since the vector was a local variable (see Figure 22).

What do we do if we want to find out the method that created the local variable? In the following message, we can get some clues, method name, line numbers, and file names.

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at LocalVariableExample.init(LocalVariableExample.java:16)
at LocalVariableExample.<init>(LocalVariableExample.java:8)
at LocalVariableTest.main(LocalVariableTest.java:5)

If you have a javacore, we can take a look at the Java stack trace of the failing thread (see Figure 23).

We can find the method name (LocalVariableExample.init), line number, and file name (LocalVariableExample.java:16) from the stack trace (see Figure 24).

Simulation of Memory Leak in a Java Thread
Let's simulate one more scenario where excessive threads are created (see Listing 4). In this experiment, we are creating millions of threads.

IBM's Java virtual machine throws the following message:

JVMDG274: Dump Handler has Processed OutOfMemory.
Exception in thread "main" java.lang.OutOfMemoryError
at NativeMemoryExhaustionSimulator.main (NativeMemoryExhaustionSimulator.java:5)

There's not enough information in the message. Sun's JVM throws the following message:

java.lang.OutOfMemoryError: unable to create new native thread
Dumping heap to java_pid6790.hprof ...
Heap dump file created [45762946 bytes in 1.521 secs]

It indicates that it was unable to create a new native thread. Probably native memory exhaustion occurred due to the excessive number of thread creation. We can take a look at the line 5 in NativeMemoryExhaustionSimulator.java to see if we are creating too many threads.

Another scenario occurs when the application might make excessive use of Java finalizers, which is explained in one of my JDJ articles. [Anatomy of Java Finalizer, Volume 14 Issue 1, Java Developer's Journal 2009]

Analysis Java Heap Leak Patterns
After years of research, I have identified that there are three different basic Java heap leak patterns that are modeled inside of the IBM HeapAnalyzer so that it can detect each pattern. The IBM HeapAnalyzer can detect these different types of memory leaks and find leak suspects for you (see Figures 25 and 26).

  1. Horizontal memory leak: Many objects are referenced from same objects
  2. Vertical memory leak: Many objects are linked together
  3. Diagonal memory leak: Combination of horizontal and vertical memory leak. It's often found in tree structures

Simulation of Horizontal Memory Leak
Believe it or not, we already have seen a horizontal memory leak in HeapExhaustionSimulator (see Listing 5). Different objects are added to an ArrayList. So many objects are referenced from the same object, ArrayList. We can clearly visualize the structure from the IBM HeapAnalyzer, which was able to detect a horizontal memory leak pattern (see Figure 27).

Simulation of a Vertical Memory Leak
We can utilize a linked list to simulate a vertical memory leak. Here's what I've come up with (see Listing 6). We are adding strings to a linked list until we get java.lang.OutOfMemoryError. The IBM HeapAnalyzer was able to detect a vertical memory leak pattern and provided a leak suspect (see Figure 28).

Simulation of a Diagonal Memory Leak
We can build up finalizable objects with the following application, DiagonalMemoryLeakSimulator (see Listing 7). From the IBM HeapAnalyzer, we can recognize a diagonal memory leak pattern. We are creating objects until java.lang.OutOfMemoryError is thrown. This is a typical tree structure thanks to java.lang.ref.Finalizer. Of course, the IBM HeapAnalzyer was able to recognize adiagonal memory leak pattern and detect a leak suspect (see Figure 29).

Conclusion
We've investigated different patterns of java.lang.OutOfMemoryError, artifacts and their possible solutions. When we see a java.lang.OutOfMemoryError and find Java heap dumps; however, it's not always necessary to analyze Java heap dumps. We often find many people blindly jumping on Java heap dumps without looking into other information. I don't think we should blame them. We just need to work smarter.

We can't diagnose all kinds of problems by analyzing the Java heap dumps alone. Java heap dumps are just snapshots of Java heap at specific times. Garbage collection trace is another source of information where we can figure out what's going on with the Java heap and garbage collector.

First, we need to determine whether java.lang.OutOfMemoryError is caused by Java heap, native memory or something else from error messages. If it's caused by native memory, we need to utilize operating system memory monitoring tools provided by an operating system such as svmon on AIX operating systems or your favorite third-party tools. If java.lang.OutOfMemoryError is related to Java heap, we need to make sure that the Java heap and parts of the Java heap are configured well enough to handle a given workload by analyzing garbage collection trace. If your JVM needs a little bit more Java heap and you have extra memory, you could endow more memory to the Java Virtual Machine in order to increase heap capacity, for example, by increasing the -Xmx command-line option. If you've already reached the address space limit, you could redistribute the workload with multiple horizontal clones of the Java Virtual Machine. If you really suspect there's Java heap leak, you are more than welcome to analyze the Java heap dumps with the IBM HeapAnalyzer or any of your favorite Java heap analysis tools.

More Stories By Jinwoo Hwang

Jinwoo Hwang is a software engineer, inventor, author, and technical leader at IBM WebSphere Application Server Technical Support in Research Triangle Park, North Carolina. He joined IBM in 1995 and worked with IBM Global Learning Services, IBM Consulting Services, and software development teams prior to his current position at IBM. He is an IBM Certified Solution Developer and IBM Certified WebSphere Application Server System Administrator as well as a SUN Certified Programmer for the Java platform. He is the architect and creator of the following technologies:

Mr. Hwang is the author of the book C Programming for Novices (ISBN:9788985553643, Yonam Press, 1995) as well as the following webcasts and articles:

Mr. Hwang is the author of the following IBM technical articles:

  • VisualAge Performance Guide,1999
  • CORBA distributed object applet/servlet programming for IBM WebSphere Application Server and VisualAge for Java v2.0E ,1999
  • Java CORBA programming for VisualAge for Java ,1998
  • MVS/CICS application programming for VisualAge Generator ,1998
  • Oracle Native/ODBC application programming for VisualAge Generator ,1998
  • MVS/CICS application Web connection programming for VisualAge Generator ,1998
  • Java applet programming for VisualAge WebRunner ,1998
  • VisualAge for Java/WebRunner Server Works Java Servlet Programming Guide ,1998
  • RMI Java Applet programming for VisualAge for Java ,1998
  • Multimedia Database Java Applet Programming Guide ,1997
  • CICS ECI Java Applet programming guide for VisualAge Generator 3.0 ,1997
  • CICS ECI DB2 Application programming guide for VigualGen, 1997
  • VisualGen CICS ECI programming guide, 1997
  • VisualGen CICS DPL programming guide, 1997

Mr. Hwang holds the following patents in the U.S. / other countries:


Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.