memory inspector

8/12/2019 Memory Inspector

1/40

Memory Inspector

Speaker: Matt Kangas

Duration of the eBook:

15 minutes


2/40


3/40

SAP AG 2003, Memory Inspector, Mathias Hanbuch, Dr. Christian Stork / 3

Content

Motivation

Memory Objects

Memory Problems

New Memory Tools for ABAP


4/40 SAP AG 2003, Memory Inspector, Mathias Hanbuch, Dr. Christian Stork / 4

Motivation

Different kinds of transactions

Former Present Short-lived online SAP

transactions, i.e. short-livedinternal 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 internalmode.

Memory leaks will take effect by

summing up as the internal

mode will not be deleted.

T1 T2 T1T3 T4 cic0

A1 A2 A3 A4

Internal modeLegend:



Content

Motivation

Memory Objects

Memory Problems




Memory Objects

Kind of Objects

Named objects

Declared with statement: DATA

Manner-of-speaking: data object, variable

Accessible by

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



Memory Objects

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.



Memory Objects

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.

itab1itab1 7

7: Table header

Table body

itab2

10



Memory Objects

Internal tables



APPEND 10 TO itab1.

APPEND 20 TO itab1.

itab2 = itab1.

APPEND 30 TO itab2.

itab1 7 itab2

7: Table header

Table body10

20



Memory Objects

Internal tables



APPEND 10 TO itab1.

APPEND 20 TO itab1.

itab2 = itab1.

APPEND 30 TO itab2.

itab2itab1 7

7: Table header

Table body10

20

itab2 8

8: Table header



Memory Objects

Internal tables



APPEND 10 TO itab1.

APPEND 20 TO itab1.

itab2 = itab1.

APPEND 30 TO itab2.

itab2itab1 7

7: Table header

Table body10

20

itab2 8

8: Table header

Table body10

20

O


12/40


Memory Objects

Internal tables



APPEND 10 TO itab1.

APPEND 20 TO itab1.

itab2 = itab1.

APPEND 30 TO itab2.

itab1 7 itab2itab2 8

8: Table header7: Table header

Table body10

20

Table body10

20

Table body10

20

30

M Obj t


13/40


Memory Objects


Internal tables

Named objects

Value semantic with Copy on write , i.e. table sharing with reference

counting.


Debugger: Access also via n{t}, where n is the id of the internal table.

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.

M Obj t


14/40


Memory Objects

Strings

str1 0 str2 0str1 2

2: Stringheader

Hallo

DATA: str1 TYPE STRING,

str2 TYPE STRING.

str1 = Hallo.

str2 = str1.

str1 = Hugo.

M Obj t


15/40


Memory Objects

Strings

str1 0 str2 0str1 2

2: Stringheader

Hallo

str2 2DATA: str1 TYPE STRING,

str2 TYPE STRING.

str1 = Hallo.

str2 = str1.

str1 = Hugo.

Memory Objects


16/40


Memory Objects

Strings

str1 0 str2 0str1 2

2: Stringheader

Hallo

str2 2

3: Stringheader

Hugo

DATA: str1 TYPE STRING,

str2 TYPE STRING.

str1 = Hallo.

str2 = str1.

str1 = Hugo.

Memory Objects


17/40


Memory Objects

Strings

str1 2str1 3 str2 0

2: Stringheader

Hallo

str2 2DATA: str1 TYPE STRING,

str2 TYPE STRING.

str1 = Hallo.

str2 = str1.

str1 = Hugo. 3: Stringheader

Hugo

Memory Objects


18/40


Memory Objects


Internal tables

Named objects

Value semantic with Copy on write , i.e. table sharing with reference counting.


Debugger: Access also v ia n{t}, where n is the id of the internal table.

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.

Memory Objects


19/40


Memory Objects


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

Memory Objects


20/40


Memory Objects



ref2 TYPE REF TO I.

CREATE DATA ref1.

ref1->* = 10.

ref2 = ref1.

ref2->* = 20.

1{r}: 01{r}: 10

ref1 0 ref2 0ref1 1

Memory Objects


21/40


Memory Objects



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

Memory Objects


22/40


Memory Objects



ref2 TYPE REF TO I.

CREATE DATA ref1.

ref1->* = 10.

ref2 = ref1.

ref2->* = 20.

1{r}: 101{r}: 20

ref1 0 ref2 0ref1 1 ref2 1

Memory Objects


23/40


Memory Objects

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.

Anonymous data objects Growth: Creating a new anonymous data object

Shrinkage: Clearing all references to a object. The garbage collector

deletes the anonymous data object.

Content


24/40


C

Introduction

Memory Objects

Memory Problems


Memory Problems


25/40


y

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.

Memory Problems


26/40


y

Example:

cic0 + F4-help

cic0

A1 A2 A3 A4

CREATE DATA dataref.

APPEND dataref TO reftab.

reftab Datref->*

CREATE DATA dataref.APPEND dataref TO reftab.

Datref->*



Datref->*



Datref->*

Content


27/40


Introduction

Memory Objects

Memory Problems




28/40


Dynamic memory objects sizes

Bound memory Minimum of memory that wil l 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


29/40


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 astring

sa : {Named objects} Bytes allocated size of a table body (internal table) ora string

obj3 str1

obj4 str2

obj5

obj1 obj2

?Boundallocated Boundused Referencedallocated Referencedused

s(obj1) s(obj1) s(obj1)+

s(obj2)

s(obj1)+

s(obj2)


sa(str2)

s(obj4)+

su(str2)

Boundallocated Boundused Referencedallocated Referencedused


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)

Boundallocated Boundused Referencedallocated Referencedused


s(obj2)

s(obj1)+

s(obj2)



30/40


TopN-Consumer-Lists (Debugger)

Finding classes and datatypes 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




31/40


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 memoryconsumption.

A lot of small-sized objects can sum up to a high memory

consumption.

Objects can be categorized by their type (= class)



32/40


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) ofthis graph.

Strongly connected components (SCCs)

List of nodes

Strongly connected components (SCC)


33/40


Root set

A strongly connected component of a directed graph is a subsetS of the graph such that for any nodes A and B of S exists alwaysa path from A to B and from B to A, and S is not a subset of anylarger such set.



34/40


Root set

A strongly connected component of a directed graph is a subsetS of the graph such that for any nodes A and B of S exists alwaysa path from A to B and from B to A, and S is not a subset of anylarger such set.



35/40


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 suff icient toclear 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.



36/40







Root set



37/40







Root set



38/40


Find References (Debugger)

Finding references to table bodies

(internal tables), str ings, objects

and anonymous data objects

keeping them alive.

Finding references to table bodies

(internal tables), str ings, 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

Anonymous data objects Strongly connected components (SCCs)

Table bodies (internal tables)

Strings



39/40


Example:

cic0 + F4-help

cic0

A1 A2 A3 A4



reftab Datref->*

t0 t1t1-t0



40/40


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

Strongly connected components (SCCs)

Comparing two memory snapshots

Newly loaded programs, classes or interfaces

Growth and shrinkage of table bodies (internal tables), strings, number of objectsor number of anonymous data objects

Memory snapshots can be analyzed in other systems

memory inspector

Documents