Memory Inspector

Memor y I nspec t or
Speaker: Matt Kangas

Duration of the eBook:
15 minutes
SAP AG 2003, Memory Inspector, Mathias Hanbuch, Dr. Christian Stork / 2
Cont ent
Motivation
Memory Objects
Memory Problems
New Memory Tools for ABAP
Cont ent
Motivation
Memory Objects
Memory Problems
Mot i vat i on
Different kinds of transactions
Former Present
Short-lived online SAP
transactions, i.e. short-lived
internal modes.
Long-lived online transactions
(e.g. CRM: cic0, SEM-BCS:
ucmon), i.e. long-lived internal
modes.
Memory leaks will not take
effect as all memory is freed
during deletion of an internal
mode.
Memory leaks will take effect by
summing up as the internal
mode will not be deleted.
T1 T2 T1 T3 T4 cic0
A1 A2 A3 A4
Internal mode
Legend:
Cont ent
Motivation
Memory Objects
Memory Problems
Memor y Obj ec t s
Kind of Objects
Named objects
Declared with statement: DATA <name>
Manner-of-speaking: data object, variable
Accessible by <name>
Value semantics
Anonymous objects
Instances of classes
Created by the statement: CREATE OBJECT
OO manner-of-speaking: object
Instances of data types
Created by the statement: CREATE DATA
SAP manner-of-speaking: anonymous data object
Accessible only via references
Reference semantics
Memor y Obj ec t s
Dynamic memory objects
Internal tables
Named objects
Value semantic with Copy on write , i.e. table sharing with reference
counting.
The table body is in fact the dynamic memory object.
Debugger: Access also via n{t}, where n is the id of the internal table.
Memor y Obj ec t s
Internal tables
DATA: itab1 TYPE TABLE OF I,
itab2 TYPE TABLE OF I.
APPEND 10 TO itab1.
APPEND 20 TO itab1.
itab2 = itab1.
APPEND 30 TO itab2.
itab1 itab1 7
7: Table header
Table body
itab2
10
Memor y Obj ec t s
Internal tables
APPEND 10 TO itab1.
APPEND 20 TO itab1.
itab2 = itab1.
APPEND 30 TO itab2.
itab1 7 itab2
7: Table header
Table body
10
20
Memor y Obj ec t s
Internal tables
APPEND 10 TO itab1.
APPEND 20 TO itab1.
itab2 = itab1.
APPEND 30 TO itab2.
itab2 itab1 7
7: Table header
Table body
10
20
itab2 8
8: Table header
Memor y Obj ec t s
Internal tables
APPEND 10 TO itab1.
APPEND 20 TO itab1.
itab2 = itab1.
APPEND 30 TO itab2.
itab2 itab1 7
7: Table header
Table body
10
20
itab2 8
8: Table header
Table body
10
20
Memor y Obj ec t s
Internal tables
APPEND 10 TO itab1.
APPEND 20 TO itab1.
itab2 = itab1.
APPEND 30 TO itab2.
itab1 7 itab2 itab2 8
8: Table header 7: Table header
Table body
10
20
Table body
10
20
Table body
10
20
30
Memor y Obj ec t s
Internal tables
Named objects
Value semantic with Copy on write , i.e. table sharing with reference
counting.
Strings
Named objects
Value semantics with Copy on write , i.e. string sharing with reference
counting.
Debugger: Access also via n{s}, where n is the string id.
Memor y Obj ec t s
Strings
str1 0 str2 0 str1 2
2: Stringheader
Hallo
DATA: str1 TYPE STRING,
str2 TYPE STRING.
str1 = Hallo.
str2 = str1.
str1 = Hugo.
Memor y Obj ec t s
Strings
2: Stringheader
Hallo
str2 2
str2 TYPE STRING.
str1 = Hallo.
str2 = str1.
str1 = Hugo.
Memor y Obj ec t s
Strings
2: Stringheader
Hallo
str2 2
3: Stringheader
Hugo
str2 TYPE STRING.
str1 = Hallo.
str2 = str1.
str1 = Hugo.
Memor y Obj ec t s
Strings
2: Stringheader
Hallo
str2 2
str2 TYPE STRING.
str1 = Hallo.
str2 = str1.
str1 = Hugo.
3: Stringheader
Hugo
Memor y Obj ec t s
Internal tables
Named objects
Value semantic with Copy on write , i.e. table sharing with reference counting.
Strings
Named objects
Value semantics with Copy on write , i.e. string sharing with reference counting.
Debugger: Access also via n{s}, where n is the string id.
Objects
Anonymous objects
Reference semantics
No reference counting
Debugger: Access via n{o}, where n is the object id.
Anonymous data objects
Anonymous objects
Reference semantics
No reference counting
Debugger: Access via n{r}, where n is the anonymous data id.
Memor y Obj ec t s
DATA: ref1 TYPE REF TO I,
ref2 TYPE REF TO I.
CREATE DATA ref1.
ref1->* = 10.
ref2 = ref1.
ref2->* = 20.
ref1 0 ref2 0
1{r}: 0
ref1 1
Memor y Obj ec t s
ref2 TYPE REF TO I.
CREATE DATA ref1.
ref1->* = 10.
ref2 = ref1.
ref2->* = 20.
1{r}: 0 1{r}: 10
ref1 0 ref2 0 ref1 1
Memor y Obj ec t s
ref2 TYPE REF TO I.
CREATE DATA ref1.
ref1->* = 10.
ref2 = ref1.
ref2->* = 20.
ref1 0 ref2 0
1{r}: 10
ref1 1 ref2 1
Memor y Obj ec t s
ref2 TYPE REF TO I.
CREATE DATA ref1.
ref1->* = 10.
ref2 = ref1.
ref2->* = 20.
1{r}: 10 1{r}: 20
ref1 0 ref2 0 ref1 1 ref2 1
Memor y Obj ec t s
Dynamic memory objects growth and shrinkage is controlled by
the programmer
Internal tables (table bodies)
Growth: Appending or inserting a new line
Shrinkage: FREE / CLEAR / REFRESH
Strings
Growth: Creating or modifying
Shrinkage: FREE / CLEAR / REFRESH and some delete operations
Objects
Growth: Creating a new object
Shrinkage: Clearing all references to an object. The garbage collector
deletes the object.
Growth: Creating a new anonymous data object
Shrinkage: Clearing all references to a object. The garbage collector
deletes the anonymous data object.
Cont ent
Introduction
Memory Objects
Memory Problems
Memor y Pr obl ems
Memory leaks
Former Present
Unintended growth of internal
tables.
Unintended long-lived internal
tables.
Objects that are
pseudo-garbage, i.e. an
application still holds
references to objects that are
no longer needed.
Anonymous data objects that
are pseudo-garbage.
Unintended growth of internal
tables.
Unintended long-lived internal
tables.
Unintended growth of strings.
Unintended long-lived strings.
Memor y Pr obl ems
Example:
cic0 + F4-help
cic0
A1 A2 A3 A4
CREATE DATA dataref.
APPEND dataref TO reftab.
reftab
Datref->*
Datref->*
Datref->*
Datref->*
Cont ent
Introduction
Memory Objects
Memory Problems
New Memor y Tool s f or ABAP
Dynamic memory objects sizes
Bound memory
Minimum of memory that will be freed, if the dynamic memory object is deleted.
Referenced memory
Maximum of memory that may be freed, if the dynamic memory object is deleted.
bound memory <= referenced memory
Table bodies (internal tables) and strings
Used memory
Memory of a table body (internal table) resp. a string that contains data of an
application.
Allocated memory
Memory of a table body (internal table) resp. a string that is allocated by the
system.
Used memory <= allocated memory
Consequently: 4 values:
Bound used
Bound allocated
Referenced used
Referenced allocated
Examples:
s : {Anonymous objects} Bytes size of an object or an anonymous data object
su : {Named objects} Bytes used size of a table body (internal table) or a
string
sa : {Named objects} Bytes allocated size of a table body (internal table) or
a string
obj3 str1
obj4 str2
obj5
obj1 obj2
?
Bound
allocated
Bound
used
Referenced
allocated
Referenced
used
s(obj1) s(obj1) s(obj1)+
s(obj2)
s(obj1)+
s(obj2)
sa(str2)
s(obj4)+
su(str2)
Bound
allocated
Bound
used
Referenced
allocated
Referenced
used
s(obj2)
s(obj1)+
s(obj2)
Rule: The size of a string or a table body is added to its fathers
size if and only if the reference count is one.
s(obj3)+
sa(str1)
s(obj3)+
su(str1)
s(obj3)+
sa(str1)
s(obj3)+
su(str1)
Bound
allocated
Bound
used
Referenced
allocated
Referenced
used
s(obj2)
s(obj1)+
s(obj2)
TopN-Consumer-Lists (Debugger)
Finding classes and data
types with high memory
consumption.
Aggregation of objects
List of instances
Aggregation of anonymous data objects
List of instances
Finding objects with high
memory consumption:
Internal tables
Strings
Objects
Table bodies (internal Tables)
Strings
Objects
The type is set during creation.
Example: DATA obj_ref TYPE REF TO some_class.
CREATE OBJECT obj_ref.
This is the type.
This is the type.
Anonymous data objects can be categorized by their type (= data
type)
The type is set during creation.
Example: DATA data_ref TYPE REF TO some_type.
CREATE DATA data_ref.
A lot of small-sized objects can sum up to a high memory
consumption.
A lot of small-sized objects can sum up to a high memory
consumption.
Objects can be categorized by their type (= class)
TopN-Consumer-Lists (Debugger)
Finding classes and data
types with high memory
consumption.
Aggregation of objects
List of instances
Aggregation of anonymous data objects
List of instances
Finding objects with high
memory consumption:
Internal tables
Strings
Objects
Table bodies (internal Tables)
Strings
Objects
Internal tables, strings, objects and
anonymous data objects form a
directed graph. Finding strongly
connected components (SCC) of
this graph.
Strongly connected components (SCCs)
List of nodes
St r ongl y c onnec t ed c omponent s (SCC)
Root set
A strongly connected component of a directed graph is a subset
S of the graph such that for any nodes A and B of S exists always
a path from A to B and from B to A, and S is not a subset of any
larger such set.
Root set
A strongly connected component of a directed graph is a subset
S of the graph such that for any nodes A and B of S exists always
a path from A to B and from B to A, and S is not a subset of any
larger such set.
To understand the memory consumption of an application it is necessary
to know the SCCs as they can be treated as one node of the graph.
That a SCC can be deleted by the garbage collector, it is sufficient to
clear all references to the SCC.
Root set
Finding the path from the root set to some node, it is important to know
the SCCs and the references to them.
Root set
Root set
Find References (Debugger)
Finding references to table bodies
(internal tables), strings, objects
and anonymous data objects
keeping them alive.
Finding references to table bodies
(internal tables), strings, objects
and anonymous data objects
keeping them alive.
Table bodies (internal tables),
strings, objects and anonymous
data objects form a directed graph.
Finding strongly connected
components (SCC) of this graph.
Objects
Table bodies (internal tables)
Strings
Example:
cic0 + F4-help
cic0
A1 A2 A3 A4
reftab
Datref->*
t0 t1
t1-t0
Creating memory snapshots
From debugger
Via method call CL_ABAP_MEMORY_UTILITIES=>
WRITE_MEMORY_CONSUMPTION_FILE( ).
OK-code /HMUSA
Analyzing and Comparing memory snapshots
From debugger
Starting transaction S_MEMORY_INSPECTOR
Via transaction code S_MEMORY_INSPECTOR
Comparison transaction S_MEMORY_INSPECTOR
Different Views
Sorted by kind of objects
TopN-Consumer-lists
Comparing two memory snapshots
Newly loaded programs, classes or interfaces
Growth and shrinkage of table bodies (internal tables), strings, number of objects
or number of anonymous data objects
Memory snapshots can be analyzed in other systems

Memory Inspector

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Memory Inspector

Uploaded by

Copyright:

Available Formats

Memor y I nspec t or

Speaker: Matt Kangas

You might also like