Mandy Chung's Blog

From Monitoring to Diagnosing Memory Problem in Mustang

Mustang Beta Release is now available!

Mustang has several enhancements in the VM and the JDK tools to help identify the symptoms and diagnose memory problems. One typical type of memory problems is memory leak causing continuously growing in heap memory usage. Eventually it may lead to OutOfMemoryError. Another typical type is the application's performance problem with excessive object creation and deletion causing long pause garbage collections. In the past, you would typically restart your application to turn on -verbose:gc option to get GC verbose tracing to determine the time GC spent and the memory usage trend. Tiger monitoring and management support enables you to continuously monitor your application at production time and catches the symptom early on. Mustang brings more...

A few techniques Mustang provides:

1. Use jconsole to watch the memory usage of your application

The memory usage graph would clearly show if the memory usage is growing over time. It also provides the low memory detection support such that you can set a threshold to catch abormal behavior. For example, I set the memory usage threshold to 6 MBytes in the Tenured Gen memory pool. The amount of memory exceeding the threshold will be flagged in red color.

2. Use jconsole to monitor the garbage collection activities

The bottom panel of the memory tab displays the garbage collection statistics including the time it spent on GC and also the total number of collections happened. It would give you a rough idea of how frequent GC happens and how long the GC takes. If you want to turn on the verbose GC tracing to get details about individual GC invocation, you can do it dynamically through JConsole as described in the "Using JConsole to monitor applications" article. You don't need to restart your application.

3. Use jconsole to find out the number of objects pending for finalization

Finalizers would be one possible cause of memory leak. There is no guarantee when a finalizer will be run and whether it will be run at all. An object that has a finalizer will not be garbage collected until its finalizer is run. JConsole shows the number of objects pending for finalization in the summary tab which would be one useful information you may want to check when you suspect a leak.

4. Obtain heap histogram to help determine the leak suspect

jmap -histo will print the histogram of the heap showing the number of instances and the amount of memory of each class. jmap -histo option was extended to support on Windows in Mustang b67. The heap histogram would give you more information to determine if a memory leak would possibly exist. Often the class with growing number of instances could be one potential leak suspect.

5. Obtain heap dump snapshots and use jhat for heap analysis

Mustang enables you to get heap dump programmatically, at runtime using jmap and jconsole, at OutOfMemoryError and also from a core file. Mustang now also includes HAT (Heap Analysis Tool) as jhat utility. Check out several blogs about Mustang heap dump and jhat:

• Heap dump is back
• Heap dump snapshot
• Query Java heap with OQL

6. Prepare for OutOfMemoryError

Alan's blog describes the improvement in OutOfMemoryError and also a new VM option -XX:+HeapDumpOnOutOfMemoryError to tell the HotSpot VM to generate a heap dump when it runs out of memory. You can either specify the VM option at startup time or at runtime via jconsole's MBeans tab.

HotSpotDiagnostic MBean provides several diagnostic operations such as to dump heap and set VM option. We plan to provide a better UI for accessing the HotSpot diagnostic features.

In summary, the diagnosability of memory problem has been improved. Download Mustang beta or the latest Mustang snapshot and let you know your feedback.

Comments

• Just tried it out in NetBeans 5 (using the shinny new JMX module) - it all looks really pretty and useful~

  Thanks for the hard work in providing us this cool tool - life as a Java programmer has again made easier!

  Posted by: alexlamsl on February 17, 2006 at 10:30 AM

• yeah! That's cool ! But how to get a appliacation 's real memory?
  what's the real? it has only its memory not others,eg.MBeans'.

  Posted by: lijiang_84 on May 09, 2006 at 05:37 AM

• Is "jmap -histo" supposed to trigger a garbage collection? If it does not trigger a garbage collection, if you are trying to figure out what objects are causing a memory leak, it will be hard to do that as the objects counts that show up in the histogram will depend on how long it has been since the last tenured GC. Any ideas on how this could be overcome?

  Posted by: veerendra_c on May 19, 2006 at 01:29 PM

• The Mustang jmap -histo shows only the reachable object counts. The current implementation triggers a garbage collection but it is subject to change. On the other hand, jmap -F -histo option counts all objects in the heap including the unreachable ones.

  Posted by: mandychung on May 30, 2006 at 11:29 AM

• How do I attach jconsole to a running 1.4.2 vm?

  Posted by: kehold on June 05, 2006 at 08:05 AM

• You can only attach to a 1.4.2 application that has a JMX agent running by specifying the JMXServiceURL of the agent. In addition, JConsole will not have any information about VM resources on a 1.4.2 application since the platform MBeans (java.lang.management API) are only available in J2SE 5.0 and later.

  Posted by: mandychung on June 06, 2006 at 12:19 PM

• very sorry about that adult webcams free adult webcam free hot webcam video free live webcam free nude webcam free webcam free webcam chat rooms free live webcam girls hot webcam live webcams webcam babes webcam girls webcam video

  Posted by: kevin36 on June 26, 2007 at 06:21 AM

This work is licensed under a Creative Commons License.