-
Notifications
You must be signed in to change notification settings - Fork 3
/
findingmemoryleak.dita
125 lines (120 loc) · 4.62 KB
/
findingmemoryleak.dita
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2008, 2023 SAP AG and others.
All rights reserved. This program and the accompanying materials
are made available under the terms of the Eclipse Public License 2.0
which accompanies this distribution, and is available at
https://www.eclipse.org/legal/epl-2.0/
SPDX-License-Identifier: EPL-2.0
Contributors:
SAP AG - initial API and implementation
IBM Corporation - more links
-->
<!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "reference.dtd" >
<reference id="ref_findingmemoryleak" xml:lang="en-us">
<title>Finding Memory Leak</title>
<shortdesc />
<prolog>
<copyright>
<copyryear year=""></copyryear>
<copyrholder>
Copyright (c) 2008, 2023 SAP AG and others.
All rights reserved. This program and the accompanying materials
are made available under the terms of the Eclipse Public License 2.0
which accompanies this distribution, and is available at
https://www.eclipse.org/legal/epl-2.0/
</copyrholder>
</copyright>
</prolog>
<refbody>
<section>
<p>
The following 4-step approach proved to be most
efficient to detect memory issues:
</p>
<ol>
<li>
Get an overview of the heap dump. See:
<i>Overview</i>
</li>
<li>
Find big memory chunks (single objects or groups of
objects).
</li>
<li>Inspect the content of this memory chunk.</li>
<li>
If the content of the memory chunk is too big check
who keeps this memory chunk alive
</li>
</ol>
<p>
This sequence of actions is automated in Memory Analyzer by the <xref href="../tasks/runningleaksuspectreport.dita">Leak Suspects Report</xref>.
</p>
<p>
The following table contains a list of queries that are
most helpful in analyzing memory leak issues.
</p>
<simpletable relcolwidth="2* 3*" id="findingmemoryleak">
<strow id="dominator_tree">
<stentry>Dominator Tree</stentry>
<stentry>
In Dominator Tree every node is responsible for
keeping its children alive. The tree is sorted
by the retained size, so you find single big
objects easily. When there is no single object
responsible for big memory consumption it is
helpful to group the result by class and class
loader to reveal big memory chunks.
</stentry>
</strow>
<strow id="top_consumers">
<stentry>Top Consumers</stentry>
<stentry>
Top Consumers query returns information about
the biggest objects grouped by class, class
loader, and package.
</stentry>
</strow>
<strow id="path_to_GC_roots">
<stentry>Paths to GC Roots</stentry>
<stentry>
Paths to GC Roots query helps to identify who is
responsible for keeping a single object in the
heap. It is reasonably to run this query on a
possible suspect (memory accumulation point),
which you can find e.g. using Big Drops in
Dominator Tree Query (see
<i>Big Drop</i>
entry further down for more details).
</stentry>
</strow>
<strow id="duplicate_classes">
<stentry>Duplicate Classes</stentry>
<stentry>
Lists classes loaded multiple times. Grouping the result by class loader points to the class loaders that load the same class multiple times. Possible cause: Several versions of the same library are deployed.
</stentry>
</strow>
<strow id="leaking_bundles">
<stentry>Leaking Bundles</stentry>
<stentry>
For snapshots for older versions of Eclopse, list bundles which are stale and
should have been garbage collected.
For newer versions of Eclipse, the duplicate classes query might be an alternative.
</stentry>
</strow>
<strow id="big_drops">
<stentry>Big Drops in Dominator Tree Query</stentry>
<stentry>
Displays memory accumulation points in the dominator tree. Displayed are objects with a big difference between the retained size of the parent and the children and the first "interesting" dominator of the accumulation point. These are places where the memory of many small objects is accumulated under one object.
</stentry>
</strow>
<strow id="leak_suspects">
<stentry>Leak Suspects Report</stentry>
<stentry>
The Leak Suspects query analyzes the heap dump, searches for memory leak and provides an illustrative description of the identified suspects.
</stentry>
</strow>
</simpletable>
</section>
</refbody>
</reference>