Since Java garbage collection isn't perfect, memory management is an important point of consideration in Java programming, as pointed out by Goran Begic in "Memory Profiling in Java" and Jim Patrick in "Handling Memory Leaks in Java Programs." In this article, I'll show how we at Wipro Technologies detected and corrected memory leaks in a Java application using the Rational Purify® for Java system testing tool, as suggested in Begic's article. I hope it will give you some idea of how this tool can be deployed and the process required to successfully remove a memory leak.

Determining Heap Usage and Memory Leakage

Purify has several options for controlling what information is actually recorded during a debugging session. After some experimentation, we decided that the most efficient way to get the required information about a memory leak is to concentrate on the captured heap data. Purify provides a view that shows the amount of heap memory in use over time as the Java application is running. The Purify GUI also provides these toolbar buttons:

• -- Garbage-collect -- to force the JVM to perform garbage collection when desired
• -- Snapshot memory profile data -- to record the data at a particular point

These capabilities turned out to be very useful when we were trying to see if a given instance of a class would be garbage-collected when it was no longer needed by the Java application. Figure 1 is a heap usage chart showing the amount of heap storage in use by our Java application over time. In the chart, the blue area indicates the amount of heap space that's been allocated for the particular screen.

After we started running our Java application and it reached a stable point, we forced the garbage collector to run, which is indicated by the sudden drop in the blue area of the Memory In Use profile. Red dots on the profile indicate the garbage collection points. Next we opened and closed one particular screen of our application, played back one test scenario, and invoked the garbage collector, followed by capturing snapshot memory profile data. The fact that the amount of memory indicated by the blue area after each checkpoint is greater than the amount before the checkpoint indicated to us that a memory leak was likely. We estimated the amount of memory leakage by looking at the difference in the values of memory at the y-axis between the second and third snapshot points in Figure 1. For more detailed calculations, we used the more advanced features in Rational Purify.

We took this approach because when we first invoke a Java application, which is a combination of various screens and screen components, the components are created and lie on the heap. When we close the screens, the components go back to the component cache (a Java class that has a number of required frequently used components) and the screens go back to the screen cache (a Java class that contains some GUI properties of the screen). When we invoke the application again, the objects of the various components aren't created from the base class but come directly from the component cache. Hence, the comparison between the second and third snapshots gives us an approximate idea of the amount of memory leakage going on in the application.

Getting Information at the Method Level

To get exact information at the method level, which is responsible for memory leaks, we used the Compare Runs tool to compare the data from the second and third snapshots. (The Compare Runs tool will display only the memory used in between two snapshots.) We saved the results as pmy and also as txt files. We opened the txt file in Microsoft Excel and filtered the data to remove the memory occupied by the Swings components or by the garbage collector. In Rational Purify we used Filter Manager. The call graph resulting from the comparison is shown in Figure 2.

The call graph in Figure 2 displays the chain of methods called between the two snapshots. This figure shows only methods with significant memory usage; other methods can be added to the report by extending the view. The highlighted chain of calls points to the method that used most of the memory during the run (highlighted in blue). This method is the first candidate for detailed analysis.

Figure 3, which gives a close look at the method list of the compared runs, confirms the obvious leak.

We added the column entitled "Method bytes allocated (diff)" to get the overall picture of the memory leak in a particular screen. Not all available columns are displayed by default. New ones can be selected from the pop-up menu when right-clicking on the Method List report. To our surprise, many times we got a negative number as the sum of these values. This result means that the memory allocated in these methods was released in between the snapshots -- that is, that the garbage collector was able to release the objects from these methods. In the expanded call graph these methods are marked in green.

Modifying Our Application

We analyzed all the screens through Purify and on the basis of the results, we made these modifications to our application:

• Removed all listeners from the destroy method of the particular screen class.
• Nullified all the components, events, variables, and renderers used in the screen in the destroy method of that screen class.
• Removed all the creation of new instance variables at the class level.
• Added a method in the event classes that nullifies all the variables / data objects / data transfer objects used in the event and called them at the time of window close before calling the destroy method.
• Avoided using too many Jpanels; instead we can reuse the already created JPanel by changing its properties if needed.
• Used the dispose method in the destroy of the screen classes. It releases all of the native screen resources used by the window, its subcomponents, and all of its owned children.

We then tested the application again with Purify. To our great satisfaction, we found that the amount of memory leakage was reduced by 90-95%.

Conclusion

Memory management needs to be attended to in Java applications despite the presence of the garbage collector. I've shown you how we used heap data captured in Rational Purify to find and correct the causes of memory leaks in our Java application. This can be a tedious process, even with a debugging tool like Purify, but the alternative is to watch program performance degrade over time as memory leaks take their toll.

Resources

• Memory Profiling in Java by Goran Begic (Rational Developer Network article)
  
  
• Handling Memory Leaks in Java Programs by Jim Patrick (IBM developerWorks article)
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers