[Android memory] using Eclipse memory Analyzer for heap dump file analysis

Reprint Address: http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html

Eclipse Memory Analyzer (MAT) is one of 33 components of the famous Eclipse Galileo version of the cross-platform integrated development environment, which is a feature-rich JAVA heap dump file analysis tool that can help you to discover and reduce memory vulnerabilities. This article mainly describes how to install configuration memory Analyzer, and in conjunction with an example, describes how to use the MAT for heap dump file analysis to find the source of memory leaks.

Overview

For large JAVA applications, fine testing is also hard to block all vulnerabilities, even though we have done a lot of good work during the testing phase, many problems are exposed in the production environment and are difficult to reproduce in a test environment. The JVM is able to record some of the operational state of the system when the problem occurs and store it in a heap dump file , providing an important basis for us to analyze and diagnose the problem.

Often memory leak analysis is considered a difficult task, typically performed by a team of experienced people. However, today we are going to introduce the MAT (Eclipse Memory Analyzer) is considered to be a "fool-like" Heap Dump file analysis tool, you only need a click of the mouse to generate a professional analysis report. Compared to other memory leak analysis tools, MAT is very easy to use, basic can achieve a key in place, even the novice can quickly get started.

The mat is so easy to use, and you are interested to feel it yourself, so the first step is to install the mat.

Prepare environment and test data

We are using Eclipse Memory Analyzer V0.8,sun JDK 6

Install MAT

Similar to the installation of other plug-ins, the mat supports two installation methods, one "standalone", which means that the user does not have to install the Eclipse IDE environment, the mat is run as a standalone Eclipse RCP application, and the other is "integrated", which means that the mat can also be used as a ecli Part of the PSE IDE, integrated with the existing development platform.

The installation of the integrated version requires the help of Update Manager.

1, first through help-software Updates ... Start the Software Updates Management wizard.

Figure 1. Install plug-in first step

Select "Available Software" and add the MAT's update address http://download.eclipse.org/technology/mat/0.8/update-site/as shown in 2.

Figure 2. Install plug-in second step

As shown in Figure 3, next select the function point of the MAT you want to install, note that the Memory Analyzer (chart) feature is an optional installation project that is primarily used to generate related reports, but if you need to use this feature, you will also need to install BIRT Char T Engine.

Figure 3. Install plug-in step three

After the plug-in is installed, you will also need to restart the Eclipse's work platform.

In comparison, the installation of stand-alone version is very simple, the user only need to download the appropriate installation package, and then unzip to run, which is commonly used as a way to install. In the example below, we are using a stand-alone MAT. Specific download requirements and addresses can be found on their product download page: http://www.eclipse.org/mat/downloads.php.

In addition, if you need to use MAT to analyze the dump file generated by the IBM JVM, additional installation of the IBM Diagnostic Tool Framework is required, as detailed in the download and installation configuration steps, see: Http://www.ibm.com/develop Erworks/java/jdk/tools/dtfj.html

Configuring Environment parameters

After the installation is complete, we also need to do some configuration work in order to use the MAT more efficiently. Because in general, it takes a lot of heap space to analyze a heap dump file, and in order to ensure the efficiency and performance of the analysis, we recommend allocating to the MAT as much memory resources as possible in a conditional situation. There are two ways you can allocate memory for more memory resources to MAT.

One is to modify the startup parameters memoryanalyzer.exe-vmargs-xmx4g

The other is to edit the file Memoryanalyzer.ini, add similar information inside the-vmargs–xmx4g.

At this point, the MAT has been successfully installed in the configuration, and began to enter the actual combat it.

Get heap dump File

Paddle, we first need to get a heap dump file. For convenience, this article uses the Sun JDK 6. Typically, as long as you set the JVM parameters as shown below:

-xx:+heapdumponoutofmemoryerror

The JVM captures the memory state at the time when a memory leak occurs, which is the heap dump file we want.

If you don't want to wait for a crash error to get a heap dump file, you can also get the heap dump file on demand by setting the following JVM parameter.

-xx:+heapdumponctrlbreak

In addition, there are a lot of tools, such as Jmap,jconsole, that can help us get a heap dump file. The example in this article is a heap dump file that uses JMap to get the Eclipse Galileo process directly. You can use the following command:

Jmap-dump:format=b,file=<dumpfile> <pid>

However, you need to be aware that heap dump files generated by different manufacturers ' JVMs have many differences in data storage formats and data storage content, and MAT is not a universal tool, and it does not handle all types of heap storage files. However, more mainstream manufacturers and formats, such as Sun, HP, SAP HPROF binary heap storage files, and IBM PHD heap storage files can be well resolved (you need to install additional plug-ins, please refer to the relevant instructions, this article does not explain in detail).

Everything is ready, and then we can start to experience the one-click Heap Storage Analytics feature.

Back to top of page

Generate Analysis Reports

First, start the previous installation of the configured Memory Analyzer tool and select the menu item File-open heap dump to load the heap dump file that needs to be parsed. After the file is loaded, you can see the interface shown in 4:

Figure 4. Overview

With the above overview, we have a general understanding of memory usage. First check the series of files that the MAT generates.

Figure 5. File list

You can see that the MAT tool provides a nice feature of compressing the contents of the report into a zip file and storing it in the repository of the original heap dump file, so if you need to analyze this memory problem with a colleague, just send the little zip package to him. There is no need to send the entire heap of files to him. And the entire report is an HTML-formatted file that can be easily opened with a browser.

Let's take a look at what is included in the generated report and help us find out what the problem is. You can generate a memory leak analysis report by tapping the Leak Suspects menu item on the toolbar, or simply click the Reports->leak Suspects link below the pie chart to generate the report.

Figure 6. Toolbar menu

Analysis of three-step curve

Usually we use the following "three steps" to analyze the memory leak problem:

First, get an overall impression of the system memory state at the time the problem occurred.

The second step is to find the culprit that is most likely to cause a memory leak, usually the object that consumes the most memory

Next, take a closer look at the specifics of this large memory consumer and see if there are any unusual behaviors.

The following is a basic example of how to use the "three steps" to view production analysis reports.

View one of the reports: Overall status of memory consumption Figure 7. Memory Leak Analysis Report

7, the most visible on the report is a simple pie chart, from which we can clearly see that a suspicious object consumes 99% of the memory of the system.

A further description of this suspicious object is also available below the graph. We can see that the memory is consumed by the Java.util.Vector instance, and Com.ibm.oti.vm.BootstrapClassLoader is responsible for loading the object. This description is very short, but I'm sure you can find a lot of clues, such as which class takes up most of the memory, which component it belongs to, and so on.

Next, we should go further to analyze the problem, why a Vector will occupy the system 99% of the memory, who stopped the garbage collection mechanism of its recycling.

View report Two: Analyzing the problem

First, we briefly review the JAVA memory recycling mechanism, the garbage collection in memory space is done by the garbage collector (garbage COLLECTOR,GC), its core idea is: the virtual machine available memory space, that is, the object in the heap space, if the object is being referenced, It is then called a surviving object, and conversely, if the object is no longer referenced, it is a garbage object that can reclaim its occupied space for redistribution.

In the garbage collection mechanism, a set of elements is called the root element collection, which is a set of objects that are directly referenced by the virtual machine, such as the running thread object, the objects inside the system call stack, and the objects that are loaded by the Systems class loader. Each object in the heap space is called by a root element as the starting point for the layer. Therefore, an object is also referenced by a surviving root element, which is considered to be a surviving object and cannot be reclaimed for memory release. Therefore, we can parse the reference path of an object to the root element to analyze why the object cannot be reclaimed successfully. If an object is not required by any program logic but there is a case where the root element is referenced, we can say there is a memory leak.

Now, let's really look for a memory leak tour and click on the "Details" link to see a detailed analysis of the suspicious object 1 shown in 8.

Figure 8. Detailed analysis report for suspicious object 1

1. We look at the shortest path from the GC root element to the memory consumption aggregation point:

Figure 9. The shortest path from the root element to the memory consumption aggregation point

We can clearly see the entire reference chain, the memory aggregation point is a collection of a large number of objects, if you are familiar with the code, believe that this information should provide you with some ideas to find memory leaks.

Next, let's take a look at what's in this object collection and why it consumes so much memory.

Figure 10. Memory consumption aggregate Object information

In this diagram, we can see clearly that this object collection holds a large number of references to the person object, which is the memory leak that it causes.

At this point, we have enough information to find the leak, back to the code, and we found that the following code caused the memory leak:

Listing 1. Code snippet for memory leak

while (1<2)  {person person  = new Person ("name", "Address", I);  V.add (person);  person = null;  }

Summarize

From the example above we can see the analysis of heap dump file with MAT, it is very simple to find the memory leak, especially for the novice, this is a Good assistant analysis tool. However, Mat is definitely not just a "fool-like" Memory analysis tool, it also provides many advanced features, such as Mat support using OQL (object query Language) to query the heap dump objects, support for threading analysis, etc., the use of these functions can be referred to Help documentation for the MAT.