Memory Inspector Concepts

To use the Memory Inspector, it's helpful to understand the concepts below.

What Does the Memory Inspector Measure?

A memory snapshot reports on the memory used by the internal session in which an ABAP program is running.

You can see both of the following:

The memory consumption directly attributable to the ABAP application. This is comprised of the memory in static and dynamic memory objects of the ABAP program, together with memory used by the program on the ABAP stack..
The memory allocation against the host operating system for the internal session as a whole. This includes both the ABAP memory consumption and the relatively small amount consumed by the ABAP runtime and internal session management.

The Memory Inspector always runs the ABAP garbage collector before taking a snapshot, so that dead memory objects do not distort the memory consumption figures.

In general, and especially because the overhead for running an internal session is small, only memory attributable to the ABAP application is important in analyzing memory problems. As a developer, you can in any case influence only the memory consumption of the ABAP program, not that of the runtime system.

Dynamic and Static Memory Objects

Of the types of ABAP memory objects, those most likely to cause problems are dynamic memory objects. Dynamic memory objects are those whose size can change as a program runs. They include the following types of ABAP entities:

Internal tables (or rather, the rows in an internal table, its body)
Strings
Class objects (objects created by the CREATE OBJECT statement)
Anonymous data objects (objects created by the CREATE DATA statement)
Boxed components

A variable for accessing a dynamic memory object contains a reference to an internal memory structure, where the data of the dynamic memory object is held. Variables for dynamic memory objects are therefore collectively known as reference variables. (In ABAP, one speaks of referenced program entities as 'deep components', components whose content must be accessed through evaluation of a reference.)

Static memory objects (Static Variables, in Memory Inspector displays), by contrast, are those whose size is set at design time by the data type declaration. The memory occupied by such variables in a program cannot change unless the program code itself is changed. Static variables are also known as 'flat variables' or 'flat components' in ABAP parlance.

Dynamic Memory Objects and Value and Reference Semantics

Value semantics and reference semantics describe two ways in which a dynamic memory object can behave when more than one variable refers to it.

The semantic used for a particular type of dynamic memory object makes an important difference in how objects of that type consume memory.

In this section, we explain which semantic applies to which types of dynamic memory objects in ABAP and how the semantic affects memory consumption.

In essence, a reference variable that uses the value semantic always has its own, unique copy of the memory object to which it refers. A value semantic variable is analogous to a static variable; like a static variable, it is bound directly to the memory object that it represents. Even though the variable is only a reference, semantically it IS the memory object itself.

A reference variable that uses the reference semantic, by contrast, is understood as a pointer to a memory object. The memory object is semantically independent of the reference variable. The object may be shared among many such variables.

Value Semantic: ABAP Internal Tables, Strings, and Boxed Components

Multiple references to ABAP internal tables, strings or boxed components are resolved using the value semantic. This means that:

Each variable for an internal table, string or boxed component points to its own, individual copy of the memory object.
Assigning a table, string, or boxed component to a second ABAP variable triggers a copy operation of the object, so that each variable has its own copy of the object.
A change made to an internal table, string, or boxed component via a particular variable is invisible to other variables that have been assigned to the same object.

Because internal tables and strings can become quite large, ABAP saves copying workload by employing a lazy copy strategy (Copy-On-Write). The initial sharing/revocation of initial sharing in static boxed components is analogous in its effect.

As long as the component remains unchanged, ABAP lets all variables that refer to the table or string point to a single memory object. Only when a table or string is changed via a variable does the ABAP runtime make a separate copy of the changed object. This lazy copy strategy means that changes to tables, strings, or boxed components can result in surprising jumps in memory consumption, as seen in the Memory Inspector.

ABAP keeps track of the variables that refer to a table, string, or boxed component by means of a reference counter. Since these entities exist only if they have reference counter values of at least 1, the ABAP garbage collector ignores these objects (unless they belong to the bound storage of a class object that is being deleted). Either at least one variable refers to a string or a table, or the string or table has been deleted.

The reference counter also determines whether a table or string counts toward the bound storage of the referencing object. Only if the counter is 1 — the referenced object belongs exclusively to the referencing object — does the referenced object count as bound memory.

Example Example

The value semantic in ABAP: Let's say variable T1 represents an internal table. You assign the internal table to variable T2 as well.

DATA t1 TYPE STANDARD TABLE OF xyz.

DATA t2 TYPE STANDARD TABLE OF xyz.

DATA t_wa type xyz.

...

t2[] = t1[].

Semantically speaking, T1 and T2 each have their own private copy of the internal table. Because of ABAP's lazy copying strategy, T1 and T2 both point currently to a single internal table in memory. If the table has 1000 rows with a length of 20 bytes, then a memory snapshot taken now will show a memory for dynamic objects of 20 KB, the size of one table.

If you now append the T_WA work area to one of the tables, the next snapshot will show that the memory for dynamic objects will have more than doubled.

APPEND t_wa TO t1.

The reason: the change to the T1 means that ABAP finally had to finish creating the table copy for T2. Each now has its own private dynamic memory object. T1's table also has one row more than T2's table.

When the APPEND occurred, ABAP saw that the reference counter to the table had a value of 2, and the dynamic memory object (the table body) needed to be copied. After the APPEND, each copy of the table has a reference counter value of 1.

End of the example.

Reference Semantic: ABAP Class and Data Objects

Multiple references to instances of ABAP classes (class objects) or to anonymous data objects are resolved using the reference semantic. This means that:

All variables that refer to a single class object or anonymous data object share a single copy of the object in memory. Assigning such an object to a variable creates a reference, never a separate copy of the referenced memory object.
A change to a class object or anonymous data object via a particular variable is visible to all other variables that refer to the same object.

Unlike tables, strings, and boxed components, instances of classes or anonymous data objects cannot suddenly manifest themselves as separate memory objects if references are added and an object is changed.

Class objects and anonymous data objects do not have reference counters. Since it is unknown whether any references to such an object exist, it is up to the ABAP Garbage Collector to find and delete memory objects that no longer are referenced.

Example Example

The reference semantic in ABAP: Assume that CO_1 represents an instance of class CL_1. You assign the instance of CL_1 to CO_2 as well.

DATA co_1 TYPE REF TO cl_1.

DATA co_2 TYPE REF TO cl_1.

CREATE OBJECT co_1.

co_2 = co_1.

Variables CO_1 and CO_2 now both point to a single class object in memory. Assume that you now change the value of ATTR1 of class CL_1.

co_1–>attr1 = 'ABC'.

CO_2–>ATTR1 now also has the value 'ABC'. Both variables continue to refer to one and the same object in memory.

End of the example.

Bound Memory

The Dominator Tree and Ranking Lists in the Memory Inspector transaction and the Memory Inspector views in the debugger refer to Bound memory. This section explains what bound memory is.

You can think of bound memory or bound storage as the main memory that would be released if a particular entity in a program — a class object, a table, a string, and so on — were deleted. Bound storage includes the memory used for the object itself as well as memory belonging to objects that are referred to and used exclusively by the object.

It is important to note, in contrast to the Memory Inspector in NetWeaver Releases before 7.0, that the bound memory number that you see includes all memory objects that are used exclusively by the reported memory object.

It is easy to tell whether a value-semantic object, such as an internal table, belongs to bound storage. If the reference counter value is 1, then the memory object is bound storage of the referring object.

But the Memory Inspector also checks reference-semantic objects, such as instances of classes, to see whether the object is exclusively used or whether there are multiple references to the object. If there is only a single reference to a reference-semantic object, then it counts as bound memory of the referring object and is shown as such in the Memory Inspector analysis views.

Example Example

Assume a class object A for which the following is true:

Class object A has as attributes an internal table and a reference to another class object C, and

Class object A has the only references to the table and the subordinate object C

In this case, the internal table and the referenced class object are part of the bound storage of class object A. If class object A is deleted, then the internal table and the class object C will also be deleted.

If the internal table had a reference counter value of 2 and another class object B also had a reference to the subordinate class object C, then the bound storage of the referring class would consist only of storage required by the class object itself. Neither the table nor the subordinate object could be deleted with the referring class object A. Further, class object C would not be deleted if class object B were deleted. C does not belong to the bound storage of B or A.

End of the example.

Used Memory and Allocated Memory

ABAP must store internal tables and strings in contiguous memory. For this reason, ABAP always allocates more storage for such objects than they actually require. The extra storage allows efficient growth to tables and strings to occur. Without the extra space, ABAP would have to copy a table or string to a larger, continuous memory space the first time that a new row is added to a table or a string is lengthened.

For strings and internal tables, the Memory Inspector shows both the storage that is actually used by the object and the storage that has been allocated to the object.

Allocated Memory is usually larger than Used Memory and represents the amount of storage that would be freed if an internal table or string is cleared or deleted.

Object Cycles or Strongly Connected Components (SCC)

ABAP class objects and anonymous data objects (in principle) can belong to strongly connected components (SCCs). Two class objects, each of which has an attribute that refers to the other, already form a strongly connected component.

SCCs are shown in the Memory Inspector in the Object Cycle (SCC) view.

SCCs are potentially important in memory analysis because an SCC may unnecessarily lock up a large amount of storage. No subcomponent of an SCC can be cleared from storage without deleting the entire SCC. A single reference to any object in the SCC from outside the SCC keeps the entire strongly connected component alive.

Finding a large SCC is a sign that you should check the program design. Is it really necessary, for example, to manage class objects in a double-linked list? If so, are there routines to discard objects from the list when they no longer are needed?

Memory Snapshots: Details

A memory snapshot contains information about the various data objects and instances of an internal session and their memory consumption. A memory snapshot is stored in a file on the application server in XML format and kept there for a maximum of 4 weeks. The index is determined through the profile parameter DIR_MEMORY_INSPECTOR. Older memory snapshots are automatically deleted, without user dialog. If you wish to keep these memory snapshots, you can have them loaded during display onto your presentation server

The file names of memory snapshots are created according to this schema: abDbgMemory_XX_YYYY, where XX is the number of the current work process and YYYY is a running numbering within the current work process. The file names are unique as long as the work process is not restarted. After a restart, the system also restarts the count and existing files can be overwritten.

If you wish to compare memory snapshots, then you should take the snapshots from a single internal session — that is, from a single execution of the program. Otherwise, it is likely that the Memory Inspector will not be able to compare the snapshots.