Arbeiten mit dem Dominatorbaum in Memory Inspector

Vorgehensweise

Wie die Rangliste zeigt die Sicht Dominatorbaum eine Liste der dynamischen Speicherobjekte in Ihrem Programm nach Größe geordnet an. Außerdem sind Querverweise auf dynamische Speicherobjekte und die Referenzen auf diese Objekte enthalten.

Der wichtige Unterschied zur Rangliste: Mit dem Dominatorbaum können Sie die Hierarchie von Referenzen auf Speicherobjekte einfach analysieren. Hier sind die Enthaltenseinbeziehungen von gebundenen Speicherobjekten in Ihrem Programm hierarchisch abgebildet. Es ist leicht ersichtlich, welche Objekte zum gebundenen Speicher anderer Objekte gehören.

Die Rangliste zeigt eine nicht differenzierte Liste der Speicherobjekte nach Größe ohne Angabe der Objektbeziehungen an.

Die Sicht im Dominatorbaum sieht folgendermaßen aus:

Abbildung 1: Der Dominatorbaum

In der Spalte Speicherobjekt werden die Speicherobjekte der obersten Ebene im internen Modus angezeigt.

Aus der Spalte Speicherobjekt ist auch die Hierarchie lokaler Speicherobjekte ersichtlich, die in anderen Objekten enthalten sind. So lässt sich beispielsweise erkennen, dass die interne Tabelle SYSTEM_TABLE von einem Attribut eines Klassenobjekts referenziert wird.

Im Dominatorbaum werden die tatsächlichen Enthaltenseinbeziehungen als Hierarchie dargestellt: SYSTEM_TABLE wird nur vom Attribut des Klassenobjekts C2{O:14} referenziert. Es gehört zu keiner anderen Referenzhierarchie. Wäre SYSTEM_TABLE kein gebundenes Speicherobjekt des Klassenobjekts, dann würde SYSTEM_TABLE nicht als im Klassenobjekt enthalten angezeigt. Stattdessen würde die Tabelle als Speicherobjekt der obersten Ebene mit einer Liste der auf sie verweisenden Referenzen dargestellt werden.
In der Spalte Referenzen werden die Attribute und Variablen mit Bezug auf die Speicherobjekte angezeigt. Dabei können Sie genau erkennen, von welcher Variable in welchem Teil des ABAP-Programms die einzelnen Referenzen gehalten werden.

Hinweis
Anders als in den Ranglisten können Sie im Dominatorbaum keine Speicherabzüge vergleichen:

Verwenden Sie den Dominatorbaum zur Analyse der Enthaltenseinbeziehungen zwischen Speicherobjekten.

Verwenden Sie die Ranglisten zur Feststellung von Änderungen zwischen Abzügen.

Sie können nicht nur feststellen, wo genau ein Speicherobjekt referenziert wird, sondern auch, wieviel Speicher von den einzelnen Objekten gebunden wird. In diesem Fall beanspruchen drei Referenzen auf separate Kopien einer internen Tabelle rund 75 MB Speicher.

Memory Inspector zeigt den tatsächlichen gebundenen Speicher eines Speicherobjekts. Der gebundene Speicher beinhaltet nicht nur exklusiv verwendete Strings und interne Tabellen, sondern auch exklusiv verwendete Klassenobjekte und anonyme Datenobjekte.

Abbildung 2: Von Speicherobjekten gehaltener gebundener Speicher im Dominatorbaum

In den bisher verwendeten Abzügen (siehe Übersicht) ging es darum, wie es zum Speicheranstieg von 50 MB zwischen dem ersten und dem zweiten Abzug kam.

Der Dominatorbaum bietet sich als ein geeignetes Werkzeug zur Beantwortung dieser Frage an. In diesem Fall ist die Antwort einfach: Die große interne Tabelle (von 25 MB) liegt jetzt in drei unterschiedlichen Kopien vor. Zwischen den beiden Abzügen hat eine Aktion des ABAP-Programms die ABAP-Laufzeit dazu gezwungen, ihr bedarfsgetriebenes Kopieren der ursprünglichen gemeinsam genutzten internen Tabelle auszuführen. (Weitere Informationen finden Sie unter Memory Inspector: Konzepte.)

Wie Sie sehen, existiert die Tabelle zwei Mal als separates Speicherobjekt im Kontext des Programms ZSP_MEMORY_ANALYSIS. Außerdem liegt sie als Speicherobjekt innerhalb des Geltungsbereiches einer Instanz einer ABAP-Klasse vor. Ausgehend von diesem Wissen können Sie jetzt das Programm analysieren, um festzustellen, ob die internen Tabellen korrekt behandelt werden.

Weiter rechts in der Anzeige sehen Sie die Statistiken Objektgröße (benutzt) und Objektgröße (allok.) für jedes Speicherobjekt. Die dort angegebenen Zahlen zeigen den vom Speicherobjekt selbst belegten Speicher an. Dieser entspricht nicht unbedingt der Größe des gesamten gebundenen Speichers.

Zum Beispiel verfügt das Klassenobjekt {O:14} in der obigen Abbildung über einen gebundenen Speicher, der über 25 Millionen Byte groß ist. Die Objektgröße jedoch beträgt nur 408 Byte, d.h. die für die Klasseninstanz selbst benötigte Speichermenge.

Bei internen Tabellen und Strings sind der gebundene allokierte Speicher und die allokierte Objektgröße identisch.

Analyse der Änderungen im Dominatorbaum

Im Folgenden soll näher untersucht werden, wie die Änderungen im Dominatorbaum zwischen zwei Abzügen zu interpretieren sind. Auch wenn Sie die Abzüge im Dominatorbaum manuell vergleichen müssen, lohnt sich die Mühe häufig.

Jetzt soll gezeigt werden, wie es zu der Schlussfolgerung kommen kann, dass die Änderungen an zwei Kopien einer internen Tabelle zu dem erhöhten Speicherverbrauch von 50 MB geführt haben.

In den obigen Abzügen beanspruchen die Variable LT_SYSTEM_TABLE im Hauptprogramm, das Attribut SYSTEM_TABLE in einer Instanz von Klasse C2 {O:14} sowie eine interne Tabelle, die im Hauptspeicher von mehreren Referenzen gemeinsam genutzt wird (das Symbol Referenz erscheint am Ende jedes Eintrags), jeweils 25 MB gebundenen Speicher.

So sah der Dominatorbaum im älteren Abzug aus, bevor der erhöhte Speicherverbrauch von 50 MB auftrat. Nur eine Kopie der großen Tabelle liegt im Speicher vor, die von der Referenzvariablen LT_SYSTEM_TABLE im Hauptprogramm gehalten wird.

Abbildung 3: Sicht des Dominatorbaums im älteren Speicherabzug

Aus der Liste der Referenzen auf LT_SYSTEM_TABLE ist ersichtlich, dass das Attribut SYSTEM_TABLE von der Instanz der Klasse C2{O:14} auf das einzelne Tabellenobjekt im Speicher zeigt - so wie tatsächlich alle Referenzen aus dem neueren Speicherabzug.

Abbildung 4: Gemeinsam genutzte Referenzen auf die interne Tabelle (LT_SYSTEM_TABLE)

Im neueren Speicherabzug weiter unten hat die Instanz der Klasse C2 ihr eigenes Speicherobjekt für die große Systemtabelle erhalten. Die Hauptprogrammvariable LT_SYSTEM_TABLE verfügt nun ebenfalls über ihre eigene persönliche Kopie der Tabelle im Speicher. Darüber hinaus gibt es noch eine gemeinsam genutzte Kopie der großen Tabelle im Hauptspeicher (als letzte Zeile im Abzug angezeigt).

Abbildung 5: Separate Tabellenspeicherobjekte im neueren Speicherabzug

Da Sie wissen, wie das bedarfsgetriebene Kopieren der ABAP-Laufzeit bei internen Tabellen funktioniert, können Sie folgern, dass der erhöhte Speicherverbrauch auf Änderungen zurückzuführen ist, die an der internen Tabelle mit der Variable LT_SYSTEM_TABLE im Hauptprogramm und mit dem Attribut SYSTEM_TABLE in der Instanz der Klasse C2 vorgenommen wurden.

Durch diese Änderungen war die ABAP-Laufzeit dazu gezwungen, das bedarfsgetriebene Kopieren der Tabelle für diese beiden Referenzen auf die Tabelle durchzuführen. Infolgedessen beansprucht jede Kopie jetzt gebundenen Speicher im Hauptspeicher, und der Speicherverbrauch des Programms hat sich um ca. 50 MB erhöht.

Verwendung des Dominatorbaums oder Verwendung der Ranglisten?

Angenommen, Sie haben beim Vergleich von zwei Speicherabzügen eine beträchtliche Erhöhung des Speicherverbrauchs in der Übersicht festgestellt.

Die Rangliste verwenden Sie, um festzustellen, welche Speicherobjekte hinzugefügt wurden oder gewachsen sind.
Die Typen-Rangliste verwenden Sie, wenn die Ursache des erhöhten Speicherverbrauchs unklar ist (keine neuen großen Speicherobjekte, wie in dem in diesem Abschnitt verwendeten Beispiel) oder wenn Sie vermuten, dass mehrere kleine Programmentitäten den Speicheranstieg ausgelöst haben. Sie können den Speicherverbrauch nach Entitätstyp überprüfen.
Den Dominatorbaum verwenden Sie, um die Enthaltenseinbeziehungen zwischen den Speicherobjekten sichtbar zu machen und genau nachzuvollziehen, welches Speicherobjekt in welchem Teil des Programms geändert oder hinzugefügt wurde.