Speicherdaten analysieren

Objektallokationen

Wenn Sie den Knoten Objektallokationen auswählen, bekommen Sie eine Liste der Klassen der instanziierten Objekte angezeigt. Dieser enthält für jede Klasse

• den vollen Klassennamen, d.h. einschl. Paketnamen, sowie dem Suffix '[]', falls es sich um eine Array-Klasse handelt

• die Anzahl der Objektinstanzen

• die aufsummierten Größe der Instanzen in Bytes, wobei die Größe einer Instanz nicht etwaige referenzierte Objekte umfasst.

Alle Tabellenzeilen sind vorne mit einem Dreieck gekennzeichnet um anzudeuten, dass sich die Zeilen durch Doppelklick expandieren lassen und dann in den Folgezeilen Detailinformationen angezeigt werden. In diesem Falle sind dies die Methodenlokationen der Allokationen in Gestalt von Stack Traces, die angeben, wo in der Anwendung die betreffenden Instanzen allokiert wurden.

Sortierung

Die Tabelle ist per Default absteigend nach der Gesamtgröße der Objektinstanzen sortiert, so dass man schnell eventuell speicherkritische Klassen identifizieren kann. Die Tabelle lässt sich mit Hilfe der üblichen Drucktasten

• nach anderen Spalten umsortieren

• nach Zeichenketten durchsuchen

• in textueller Form exportieren (ohne Stack Traces bzw. nur mit den momentan expandierten Stack Traces bzw. mit allen Stack Traces)

Klassenstatistik

Wenn Sie den Knoten Klassenstatistik auswählen, bekommen Sie eine Tabelle der "lebendigen" (d.h. noch referenzierten) Objekte nach einer der während der Profiling-Sitzung durchgeführten VM-lokalen Garbage Collection auf. Sie können in der Kopfzeile die Nummer der GC und der VM auswählen, deren Klassenstatistik Sie sehen möchten.

Die Statistik unterscheidet zwischen sog. "jungen" (young) und "alten" (old) Objekten. Alte Objekte sind solche, die schon eine gewisse Anzahl von GCs überlebt haben, was für junge Objekte noch nicht gilt. Diese Altersgrenze kann ebenfalls in der Kopfzeile ausgewählt werden. Default-Wert ist 4.

Weitere Informationen: Funktionsweise des Local Garbage Collectors

Die Tabelle enthält folgende Informationen:

• voller Klassennamen, d.h. einschl. Paketnamen, sowie dem Suffix '[]', falls es sich um eine Array-Klasse handelt

• Anzahl der Objektinstanzen

• summierte Nettogröße in Bytes der Instanzen, wobei die Größe der Instanz nicht etwaige referenzierte Objekte umfasst

• summierte Bruttogröße in Bytes der Instanzen, wobei die Größe der Instanz auch etwaige referenzierte Objekte umfasst.

Die letzten drei Werte werden in separaten Spalten für

• junge Objekte (Spalten mit führendem "Y" für "young")

• alte Objekte (Spalten mit führendem "O" für "old")

• alle Objekte zusammen (Spalten mit führendem "T" für "total")

aufgelistet.

Sortierung

Die Tabelle ist per Default absteigend nach der Bruttogröße der alten Objekte sortiert, so dass Sie schnell eventuelle Kandidaten für Speicherlecks identifizieren können. Die Tabelle lässt sich mit Hilfe der üblichen Drucktasten bearbeiten (umsortieren, summieren, drucken etc.).

Grafische Information

Ein Doppelklick auf eine Tabellenzeile liefert eine Liniengrafik, die die Altersentwicklung der Objekte der betrachteten Klasse unter der Überschrift "Statistik lebendiger Objekte für Klasse: <Klassenname>" dargestellt. Die X-Achse repräsentiert die Zeit in Gestalt der aufeinander folgenden GC-Läufe. Auf der Y-Achse sind die Anzahlen der Objekte nach Beendigung jeder GC aufgetragen. Drei Grafen repräsentieren die Objekte der jungen, mittleren und alten Generation. Die Generationengrenzen werden aus der eingestellten Altersgrenze abgeleitet und sind der Farblegende unter dem Diagramm zu entnehmen.

Mögliche Speicherlecks erkennen

Normalerweise sollte die Anzahl junger und alter Objekte über die Zeit mehr oder weniger konstant bleiben. Eine steigende Anzahl von alten Objekten deutet auf ein Speicherleck hin, da Objekte von den GCs offenbar nicht erfasst wurden.

Referenzketten

Wenn Sie den Knoten Referenzketten auswählen, bekommen Sie eine Liste der Referenzketten für alle erreichbaren (d.h. noch referenzierten) Objekte nach einer der während der Profiling-Sitzung durchgeführten VM-lokalen Garbage Collections auf. Sie können in der Kopfzeile die Nummer der GC und der VM auswählen, deren Referenzketten Sie sehen möchten.

Die Liste enthält folgende Informationen:

• voller Klassennamen und dem Classloader-Namen im Format <classname>@<loadername> #id, wobei id eine eindeutige interne Kennung des Classloaders ist

• Anzahl der Objektinstanzen dieser Klasse

Alle Zeilen sind vorne mit einem Dreieck gekennzeichnet um anzudeuten, dass sich die Zeilen durch Doppelklick expandieren lassen und dann in den Folgezeilen Detailinformationen angezeigt werden. In diesem Falle sind dies die vollständigen Referenzketten der einzelnen Instanzen. Um die Anzeige übersichtlich zu halten, werden die Ketten zunächst in Untergruppen eingeteilt. Durch fortgesetztes Expandieren können Sie sich schließlich die detaillierte Referenzketten anzeigen lassen.

Sie bekommen folgende Referenzangaben:

• "stored in field 'xyz' of"

• "stored in static field 'xyz' of"

• "stored at index nn in array"

• "the class of object"

• "is the superclass of"

• "is the root of the shared closure, which contains"

• "stored in global root"

So erhalten Sie Auskunft darüber, über welche Objekte und Klassen Referenzen auf die betrachtete Instanz gehalten werden. Das letzte Element der Kette ist das Objekt, das die betrachtete Instanz über diese Kette letztendlich "am Leben hält". Man beachte, dass ein und dieselbe Instanz durchaus über mehrere Ketten gleichzeitig am Leben gehalten werden kann. Die Tabelle enthält in solchen Fällen jedoch immer nur eine der Ketten.

Sortierung

Die Tabelle ist per Default absteigend nach der Anzahl der Objektinstanzen einer Klasse sortiert, so dass man schnell die Kandidatenklassen für Speicherlecks identifizieren kann. Bei der Nachverfolgung der Referenzketten würde man letztendlich auf die kritischen Objekte stoßen, die die Instanzen am Leben halten.

VM-lokale Garbage Collection:

Wenn Sie den Knoten GC Statistiken auswählen, bekommen Sie die Statistiken für alle VM-lokalen Garbage Collections, die während der Profiling-Sitzung durchgeführt wurden (vgl. Funktionsweise des Local Garbage Collectors). Falls man nicht eine VM für das Profiling reserviert hatte, umfasst sie die GCs in allen VMs des VM Containers.

Im oberen Teil der Anzeige sind die Kopfdaten der GCs in einer Tabelle zusammengefasst. Die Tabelle listet die GCs auf und beinhaltet folgende Informationen

• interne Nummer der VM, in der die GC durchgeführt wurde

• interne Nummer der GC

• Typ der GC ("full" = vollständig, "partial" = teilweise, "shared" = Beitrag zu einer Shared GC)

• der Grund für die GC (z.B. "allocation failed" = Speicheranforderung schlug fehl, oder "requested by shared GC" = die lokale GC war Teil einer VM-übergreifenden GC)

• Größe des angeforderten Speichers in Bytes, falls der Grund für die GC eine fehlgeschlagene Speicheranforderung war)

• Zeitspanne in Mikrosekunden zwischen Beginn und Ende der GC

• CPU-Zeit in Mikrosekunden, die von der GC verbraucht wurde

• Anzahl der Page Faults, die während der GC auftraten. Ein großer Wert deutet darauf hin, dass der Heap-Speicherbereich der VMC-VM zu groß konfiguriert sein könnte.

• Uhrzeit und Datum, wann die GC begonnen hat

Wählen Sie in der Tabelle eine Zeile durch Doppelklick aus, so werden im unteren Teil der Anzeige die vollständigen Statistikdaten der betreffenden GC eingeblendet. Die Bedeutung der einzelnen Werte können Sie den F1-Hilfetexten zu den betreffenden Bezeichnern bzw. Ausgabefeldern entnehmen. Die Werte sind wie folgt gruppiert.

• Kopfdaten: Dies sind dieselben Werte wie in den Tabellenzeilen.

• "Young Generation": Alle Objekte werden zunächst in diesem Speicherbereich allokiert. Erst wenn sie eine gewisse Anzahl von GCs (festgelegt im Systemprofil-Parameter xyz) überlebt haben, werden sie in den Speicherbereich der "Old Generation" verlagert (promoted). Die Werte in dieser Gruppe geben also Aufschluss über den Anteil der kurzlebigen Objekte im Speicher.

• "Old Generation": In diesem Speicherbereich landen alle Objekte, die eine gewisse Anzahl von GCs überlebt haben. Die Werte in dieser Gruppe geben also Aufschluss über den Anteil der langlebigen Objekte im Speicher.

• Klassen: Die Werte in dieser Gruppe geben Aufschluss über den Anteil der Klassenobjekte im Speicher.

• java.lang.Reference-Objekte: Die Bedeutung dieser Objekttypen, die sich noch einmal in die folgenden Unterklassen

  • SoftReference

  • WeakReference

  • PhantomReference

  • FinalReference

  gliedern, entnehme man den zugehörigen F1-Hilfetexten.

Sortierung

Die Tabelle ist per Default nach den VM-Nummern und innerhalb einer VM nach den GC-Nummern sortiert, so dass die GCs in der Regel in chronologischer Reihenfolge erscheinen.

Shared Garbage Collection:

Wenn Sie den Knoten SharedGC Statistiken auswählen, bekommen Sie die Statistiken für alle VM-übergreifenden Garbage Collections (Shared GCs), die während der Profiling-Sitzung durchgeführt wurden.

Bei der Interpretation der Statistiken benötigen Sie Kenntnisse über den Algorithmus der Shared GC. Informationen dazu finden Sie unter Funktionsweise des Shared Garbage Collectors.

Die Shared GC verwendet einen verteilten Algorithmus. Ein abgeschlossener Shared GC-Zyklus durchläuft drei Phasen:

1. Start: Eine VM löst die Shared GC aus, z.B. durch eine VM-lokale vollständige GC. Alle VM-übergreifenden Objekte werden markiert, und es wird eine Liste der VMs erstellt, die zur GC beizutragen haben.

2. Beitrag: Alle VMs auf dieser Liste leisten ihren Beitrag, indem sie die Markierung der von ihnen noch referenzierten VM-übergreifenden Objekte löschen. Dies erfordert zunächst eine vollständige lokale GC innerhalb der VM.

3. Freigabe: Nachdem alle erforderlichen VMs ihren Beitrag geleistet haben, wird der Speicher der noch markierten Objekte freigegeben.

Im oberen Teil der Anzeige sind die Kopfdaten der Shared GCs in einer Tabelle zusammengefasst. Die Tabelle listet die GCs auf mit folgenden Informationen.

• interne Nummer der Shared GC

• Grund für die Shared GC (z.B. "shared allocation failed" = Speicheranforderung schlug fehl, oder " shared watermark exceeded" = der VM-übergreifende Speicher hat einen gewissen kritischen Füllstand überschritten)

• Größe des gewonnenen (d.h. bei der Shared GC freigegebenen) Speichers in Bytes

• Zeit in Mikrosekunden zwischen Beginn und Ende der Freigabephase dieser Shared GC

• Uhrzeit und Datum, wann die Shared GC begonnen hat

Wählen Sie in der Tabelle eine Zeile durch Doppelklick aus, so werden im unteren Teil der Anzeige die vollständigen Statistikdaten der betreffenden Shared GC eingeblendet. Die Bedeutung der einzelnen Werte können Sie den F1-Hilfetexten zu den betreffenden Bezeichnern bzw. Ausgabefeldern entnehmen. Die Werte sind wie folgt gruppiert.

• Kopfdaten: Die Bedeutung der Werte ist wie in den Tabellenzeilen.

• "Freigabe-Phase": Die Werte in dieser Gruppe geben Aufschluss über die Kernaktivität der Shared GC.

• "Freigegebene Shared Items": Hier ist angegeben, wie viele Objekte der 5 Typen von VM-übergreifenden Speicherobjekten (Shared Class Loaders, Shared Classes, Shared Closure Versions, Shared Interned Strings und Shared Locks) bei dieser Shared GC freigegeben wurden.

• "Shared Classes": Die Gesamtgrößen in Bytes aller Klassen vor und nach dieser Shared GC geben Aufschluss über den Anteil von Klassenobjekten im VM-übergreifenden Speicher.

• "Shared Data": Die Gesamtgrößen in Bytes vor und nach dieser Shared GC geben Aufschluss über den Anteil von allen übrigen Objekttypen im VM-übergreifenden Speicher.

• "Shared Memory Pool": Die Prozentwerte geben Aufschluss über den Füllstand des VM-übergreifenden Speichers vor und nach der Shared GC.

Sortierung

Die Tabelle ist per Default nach den GC-Nummern sortiert, so dass die Shared GCs in der Regel in chronologischer Reihenfolge erscheinen.

Shared Closure-Operationen

Wenn Sie den Knoten SharedClosure Operationen auswählen, bekommen Sie eine Liste der Shared Closures, auf die während der Profiling-Sitzung zugegriffen wurde, die für jede Shared Closure folgende Informationen beinhaltet:

• voller Name, d.h. einschl. Closure Domain Namen. Trennzeichen im Pfad der Closure Domain ist der Schrägstrich ('/').

• interne Id, mit der die Shared Closure im VMC eindeutig identifiziert ist;

• Versionsnummer

• Häufigkeit und Größe in Bytes, mit der die Operationen

  • Anlegen (CREATED)

  • Kopieren (COPIED)

  • Einblenden (MAPPED)

  • Löschen (DELETED)

  auf den einzelnen Versionen der Shared Closures angewendet wurden.

Versionierung

Ist eine Tabellenzeile vorne mit einem Dreieckssymbol gekennzeichnet, so wurde die Shared Closures in mehreren Versionen verwendet, und die Tabellenzeile enthält die über alle Versionen summierten Werte. Durch Doppelklick lassen sich solche Zeilen expandieren. In den Folgezeilen werden dann die Einzelwerte der Versionen angezeigt.

Bei Shared Closures mit nur einer Version ist die Versionsnummer im Format #<Versionsnummer> an den Closure-Namen angehängt.

Sortierung

Die Tabelle ist alphabetisch aufsteigend nach den vollen Shared Closure Namen sortiert.