User Guide
|
 |
 |
|
|
 |
 |
Using the BEA JRockit Memory Leak Detector
The BEA JRockit Memory Leak Detector is a tool to detect memory leaks within Java applications running on BEA JRockit. A memory leak means application code holding on to memory which is not actually used by the application any more. The BEA JRockit Memory Leak Detector is a real-time profiling tool that gives information about what type of objects are allocated, how many, of what size and how they relate to each other. Unlike other similar tools, there is no need to create full heap dumps to be analyzed at a later stage. The data presented is fetched directly from the running JVM and the JVM can continue to run with a relatively small overhead. When the analysis is done, the tool can be disconnected, and the JVM will run at full speed again. This makes the tool viable for use in a production type environment.
The purpose of this tool is to display memory leaking object types and provide help to track the source of the problem. Another purpose of this tool is to help the developer by increased understanding and knowledge to avoid similar programming errors in future projects.
Note: To access the full version of the BEA JRockit Memory Leak Detector, JRockit JRockit 1.4.2_05 or higher is required.
This section describes the BEA JRockit Memory Leak Detector (from now on referred to as Memory Leak Detector) and how to use it to detect memory leaks. It includes information on the following subjects:
- Starting the Memory Leak Detector
- Using the Memory Leak Detector
- Help Us Improve BEA JRockit
- BEA JRockit Support for the Memory Leak Detector
- Frequently Asked Questions
- Known Issues
Starting the Memory Leak Detector
To start the Memory Leak Detector you need to start the BEA JRockit Management Console (as from BEA JRockit 1.4.2_05):
- Start your Java application with BEA JRockit as usual, but add the
-Xmanagementoption to the command line. - Start the Management Console and connect to the BEA JRockit you just started. (See Start the JRockit Management Console for details on how to do this.)
Figure 5-1 displays the content of this tab.
Figure 5-1 MemLeak Detector Tab in the BEA JRockit Management Console
- Click Enable memleak system. This automatically starts the trend analysis, which causes information about different object types to be displayed in the Trend analysis table.
In Table 5-1 you can find detailed explanations of what each column stands for. When starting the memory leak data collection you also get a message from JRockit that the "ManagementServer started trend analysis".
Using the Memory Leak Detector
This section describes how to use the Memory Leak Detector. You will find the following topics:
- Overview of the Memory Leak Detection Process
- Getting Started
- Memory Leak Detection
- An Example of How to Find a Real Memory Leak
Overview of the Memory Leak Detection Process
The memory leak detection process consists of three phases:
Trend analysis means to observe continuously updated object type related information and try to discover object types with suspicious memory growth. These object types should then be studied in the next phase of the memory leak detection process. The information in the trend analysis table will be updated each time a garbage collection is performed.
Studying object type relations means repeatedly following reference paths between object types, i.e. classes. The goal is to find interesting connections between growing object types and what types of objects points to them. Finding the object type guilty of the unusual memory growth will lead to the third and final phase of the memory leak detection process.
Instance investigation consists of finding an instance of abnormal memory size or holding an abnormal amount of references and then inspect that instance. When inspecting an instance, values will be displayed, e.g. field names, field types, and field values. These values will hopefully lead you to the correct place for the error in the application code, i.e. where that particular instance of that particular object type is allocated, modified, or removed—depending on what the situation implies. Minimizing the problem areas to the ones connected to the suspected instance will most likely lead you on the right track to finding the actual problem causing the memory leak and fix it.
Getting Started
To analyze an application you need to start the Memory Leak Detector (see Starting the Memory Leak Detector).
- Click Enable memleak system to start the continuous update of profiling data, the result should look something like Figure 5-2.
Figure 5-2 Memory Leak System Enabled
Memory Leak Detection
The following sections will guide you on how to use the Memory Leak Detector to help you with the memory leak detection process.
- Mark any object type you find interesting. Probably one with a high growth value (most likely marked red or yellow).
A menu appears, see Figure 5-3.
Figure 5-3 Marking Suspect Object Type
The Referring Types Window appears that displays a list of the object types pointing to that particular type of object, see Figure 5-4.
Figure 5-4 Referring Types Window: Investigating Suspicious Object Types
- Mark an object type you wish to study and right-click, the different action alternatives appear, see Figure 5-5.
- Show types pointing to this type alternative (see how to in section 4.).
- Show largest array of this type if the selected object type happens to be an array. This function lists the ten largest array instances of this type in the Largest Arrays Window, see Figure 5-6.
- Show instances of this type pointing to <TYPE>. This alternative lists—if it is not too large—all instances of the selected object type pointing to objects of type TYPE in the Referring Instances Window, see Figure 5-7.
- Follow the suspicious instances in Figure 5-6 by selecting and right-clicking the selection and choosing Show instances pointing to this array.
In the new Referring Instances Window that appears, see Figure 5-7, you can see static fields and how many thread roots are referring to the instance in question.
Figure 5-7 Referring Instances Window: Instances Pointing to an Array Instance.
- Click Inspect. The Inspection Window appears, see Figure 5-8.
When inspecting an instance you get all necessary data to hopefully track the particular instance in the application code. You get the field names, their types, and their values. Trying to map these values to the code will help you discover the source of the memory leak.
Figure 5-8 Inspection Window: Inspecting an Instance
Figure 5-5 Available Action Alternatives
Figure 5-6 Largest Array Window: Looking at the Largest Array Instances
In some cases the lists that is displayed may be very long. In those cases you will be notified and informed about the consequences of displaying such a list, see Figure 5-9.
Figure 5-9 Trying to display a very long list
An Example of How to Find a Real Memory Leak
Below follows an example of how to find a memory leak by narrowing down the search space. Once the search space is narrowed down, you will hopefully find the exact problem area and then be able to solve the problem by changing you application.
After starting the Memory Leak Detector, choose to investigate the object type that grows the most and which is not expected to grow, considering the design and the purpose of the application. In this example it turns out to be the DemoObject object type (Figure 5-10). Select the row corresponding to the suspected object type, right-click on it and choose the menu option Show types pointing to this type.
Figure 5-10 Trend Analysis Gave the Object Type DemoObject
A Referring Types Window (Figure 5-4) appears displaying the one object type pointing to the DemoObject. It turns out to be HashTable$Entry. To pursue this suspected memory leak path, select the corresponding row, right-click on the selection, and choose Show types pointing to this type once again.
In the new Referring Types Window that appears, note the two object types pointing to the previous object type. One is HashTable$Entry[ ] and the other is HashTable$Entry. Notice that the number of references from the HashTable$Entry[ ] type is much larger than expected and choose to investigate this array type further. Select the row corresponding to the array type, right-click the selection, and choose Show types pointing to this type. By selecting this option, you find that the object type HashTable is pointing to the array in the new Referring Types Window that appeared.
Return to the previous window and select the suspected array type again. Right-click on the selection, but this time choose Show largest arrays of this type. A Largest Array Window (Figure 5-6) appears with a list of the ten largest instances of this array, with the largest listed on top. This information tells you that it is one single array instance being responsible for the large memory occupation.
Instead of choosing the other alternative: Show instances of this type pointing to <TYPE>, where TYPE in this case is HashTable$Entry the new window that appears presents a warning for a large amount of references maybe causing the connection to the JRockit process to be lost. This means that the HashTable$Entry[ ] consumes unexpected amounts of memory and is holding on to an enormous amount of references to HashTable$Entry.
Return to the Largest Array Window. Select and right-click the suspected alternative, i.e. the instance occupying the largest amount of memory. Select Show instances pointing to this array. A Referring Instances Window (Figure 5-7) appears with a list of instances pointing to the array. It is a HashTable instance (Figure 5-11).
Figure 5-11 Studying Object Type Relations Resulted In the Following Schedule
The Inspection Window (Figure 5-8) appears. In that window you can see different field names, their types, and their values (Figure 5-12). Pretty soon you will probably be able to map these fields and values to a certain point in the application code.
Figure 5-12 Instance Inspection Helps Mapping the Problem to Corresponding Code
From this example, you can draw the conclusion that somewhere you add HashTable$Entry instances into the HashTable$Entry[ ] which is kept alive by a HashTable. You can also read that your application never seems to remove them, since the memory occupied by these type of objects is continuously growing. To confirm the beliefs, investigate the code thoroughly at the place where the instance field info has taken you.
The source of the confirmed memory leak turned out to be in a place in the code where, after HashTable$Entry objects are added to the HashTable$Entry[ ] in a HashTable. The application removed all of the HashTabe$Entry objects except one; it missed the last instance due to an off-by-one error (a very common error causing memory leaks of this sort).
Help Us Improve BEA JRockit
The Memory Leak Detector provides an easy way to capture information about object type allocation statistics. It is designed to help developers to easier find memory leaks and to better understand critical points of program engineering.
If you have any suggestions relevant for this purpose on how to improve this tool or information on how it is most commonly used in development environments, we would be grateful to receive your input. This information would contribute to our understanding on how to best further improve this tool in the future.
Please, send an email with feedback and your ideas on how to use it to:
How will BEA Systems Use This Feedback
The feedback will be considered by the development team designing the Memory Leak Detector. We will look at collected ideas and improve the tools of BEA JRockit to make them even easier to use. Our goal with the development of this tool is to simplify the difficult task of finding memory leaks in the future and help the developer work more efficiently.
BEA JRockit is already providing a lot of appreciated manageability tools, and to stay appreciated and to keep a close dialogue with developers using Java Runtime Environments, BEA Systems is always trying to find ways to improve BEA JRockit. This is one of the ways.
BEA JRockit Support for the Memory Leak Detector
Only more recent versions of BEA JRockit fully support the Memory Leak Detector: BEA JRockit 1.4.2_05.
Frequently Asked Questions
Following are some questions we have frequently been asked about the Memory Leak Detector:
- Does BEA Systems Guarantee the Accuracy of this tool's output?
- Does the Memory Leak Detector Cause Any Overhead?
- What Kind of Support is Available for the Memory Leak Detector?
- Is There a Forum Where I can Discuss the Memory Leak Detector?
Does BEA Systems Guarantee the Accuracy of this tool's output?
Since this is not a supported product, we cannot make any guarantees about the correctness of the data we show or the stability of the product when using the Memory Leak Detector.
Does the Memory Leak Detector Cause Any Overhead?
During the first phase of the memory leak detection process the data presented is continuously updated; however, the overhead during this phase is very small. During the second and third phase the only overhead that will be caused is some additional garbage collections which in most cases is negligible. Overall, there is practically no overhead and it should not affect the speed or results of your application.
What Kind of Support is Available for the Memory Leak Detector?
The Memory Leak Detector functionality is currently being provided as-is for your convenience and to help with memory leak detection and is not supported by BEA Support.
Is There a Forum Where I can Discuss the Memory Leak Detector?
If you have any questions you are welcome to share them in the BEA JRockit general interest newsgroup, which is monitored by our engineering team. To access the newsgroup, go to:
Known Issues
Sometimes static fields and the number of thread roots are not correctly displayed in the window displaying instances referring to an other instance. This can be helped by starting the memory leak detection process one again (i.e. unfreezing and freezing the memory leak system). However, if there is data displayed, it is the correct values.
