This one might be interesting for you, if you search for
memory leaks.
Instances of classes or simply "objects" are created by CREATE OBJECT. Anonymous data objects are created by CREATE DATA. After creation, references (object references and data references) contained in reference variables are pointing to these objects. We all know that the objects are kept alive by these references and that they are deleted by the garbage collector if they are not referenced any more. But what kind of references are keeping objects alive? Let's have look.
We start with the memory where objects are stored. In the working memory of an ABAP program (the well known roll area of an internal session) we can distinguish two further memory areas:
- The heap - the heap is the memory where all objects created by the CREATE statements, i.e. instances of classes and anonymous data objects, are stored.
- The stack - the stack is the memory where the (named) data objects of programs and procedures are stacked. The memory occupied by the local data of a procedure (including methods) is popped from the stack, when the execution of the procedure has finished.
Now it is easy to distinguish two types of reference variables:
- Heap references -heap references point to objects and parts of objects in the heap. Heap references are created when new objects are created with CREATE OBJECT or CREATE DATA. But you can also create heap references using the statement GET REFERENCE or the addition REFERENCE INTO for data objects or part of data objects in the heap.
- Stack references - stack references. point to objects and parts of objects in the stack. Stack references can be created only using the statement GET REFERENCE or the addition REFERENCE INTO for data objects or part of data objects in the stack.
An
object reference is always pointing to an instance of a class in the heap and therefore an object reference is always a
heap reference.
A
data reference is a
heap reference, if it points to an instance attribute or a part of an instance attribut of an object in the heap, or if it points to an anonymous data object or a part of an anonymous data object in the heap. A data reference is a
stack reference, if it points to a data object or a part of a data object on the stack. A part of an instance attribute or of a data object can be a component of a structure, a line of an internal table, or a section specified by an offset and length.
And now about keeping objects alive:
- Heap references pointing to objects or parts of objects in the heap keep the objects alive.
- Stack references pointing to (data) objects or parts of (data) objects in the stack do not keep the objects alive.
With other words and for example: A data reference pointing to a line of an internal table that is an instance attribute of an object keeps the object alive, even if you have cleared the object reference variable!
CLASS cls DEFINITION.
PUBLIC SECTION.
DATA itab TYPE TABLE OF i.
METHODS constructor.
ENDCLASS.
CLASS cls IMPLEMENTATION.
METHOD constructor.
APPEND 1 TO itab.
ENDMETHOD.
ENDCLASS.
DATA: oref TYPE REF TO cls,
dref TYPE REF TO data.
START-OF-SELECTION.
CREATE OBJECT oref.
READ TABLE oref->itab INDEX 1 REFERENCE INTO dref.
CLEAR oref.
WAIT UP TO 1 SECONDS.
IF dref IS BOUND.
MESSAGE 'Alive!' TYPE 'I'.
ENDIF.
And even more:
Field symbols pointing to objects or part of objects in the heap (if you use the statement ASSIGN or the addition ASSIGNING for heap objects or part of heap objects) also keep the objects alive!
Last but not least a word about
validity: Since heap references keep objects alive, as a rule they are always
valid (IS BOUND is true). But ABAP wouldn't be ABAP if there were not one exception from that rule: Internal tables are dynamic data objects with an own memory management that is independent from CREATE and garbage collection. A data reference pointing to a line of an internal table in the heap is a heap reference and keeps the table and its surrounding object alive. Nevertheless, it can become invalid (IS BOUND is false) if the internal table line is deleted from the table. For strings you could expect the same, but ABAP does not allow you to point to sections of strings with references or field symbols. Stack references can always become invalid of course, if the referenced objects are popped from the stack.
