Logging der GC Aktivität
java -Xloggc:C:\gc.log
Standardausgabe
java -verbose:gc
Ausgabe
1536.662: [GC 63620K->47590K(260160K), 0.0049590 secs]
1536.799: [GC 63420K->48154K(260160K), 0.0062494 secs]
1552.139: [GC 64346K->47985K(260160K), 0.0026610 secs]
1591.715: [Full GC 54093K->44582K(260160K), 0.9023136 secs]
1690.079: [GC 60774K->45041K(260160K), 0.0034161 secs]
1749.963: [Full GC 54661K->43586K(260160K), 0.3904586 secs]
1768.842: [Full GC 47060K->42993K(260160K), 0.9170143 secs]
1870.667: [GC 59185K->43273K(260160K), 0.0027372 secs]
| 1870.667 | Zeitstempel |
| 59185K | Der belegte Heap Speicher vor der Speicherbereinigung |
| 43273K | Der belegte Heap Speicher nach der Speicherbereinigung |
| 260160K | Gesamtgröße des Heaps minus ’survivor spaces‘ |
| 0.0027372 secs | Dauer der Speicherbereinigung |
Die Log-Ausgabe kann zum Beispiel mit der Anwendung TailMe angezeigt oder mit GCViewer visualisiert werden.
Visualisierung der Garbage-Collection Aktivität
Der rote Bereich markiert den gesamten Heap Speicher. Der verwendete Speicher wird durch die blaue Linie visualisiert.
Wie man aus der Abbildung ersehen kann, wird bei der Bereinigung nicht der gesamte Heap freigegeben.
Seit VM 1.3 ist der sogenannte „Generationen-Kollektor“ im Einsatz. Es wird nur der Teil des Heaps aufgeräumt, der für die „junge Objekte“ reserviert wurde. Diese Vorgehensweise ist schneller als eine vollständige Speicherbereinigung, da bei eine vollständige Bereinigung das Programm angehalten werden muss.
Der folgende Absatz stammt aus der Ausarbeitung von „Angelika Kusel“ zum Thema „Garbage Collection“.
Download: GarbageCollection.pdf
Der Heap kann durch zahlreiche Kommandozeilenparameter an die eigenen Bedürfnisse angepasst werden. Gerade in großen Anwendungen kann die Optimierung des Heaps zu einem beträchtlichen Performance-Gewinn beitragen.
Anpassung/Optimierung des Heaps
-XX:+UseParallelGC aktiviert parallele „Mark and Compact“ Verfahren.
Parameter, die die gesamte Heapgröße betreffen
-Xms
-Xmx
-XX:MinHeapFreeRatio
-XX:MaxHeapFreeRatio
-Xms stellt die minimale Heapgröße (und damit auch gleichzeitig die Heapgröße zu Beginn) dar. Der Wert von -Xms muss ein Vielfaches von 1024 Bytes sein und größer als 1 MB. Der default-Wert beträgt 2 MB.
-Xmx stellt die maximale Heapgröße dar. Der Wert von –Xmx muss ebenfalls ein Vielfaches von 1024 Bytes sein und größer als 2 MB. Der default-Wert beträgt 64 MB. Für große Anwendungen ist der de-fault-Wert von 64 MB oft zu klein.
Beispiel:
-Xms6291456 //Angabe in Bytes
-Xms6144k //Angabe in KB
-Xms6m //Angabe in MB
Aus der Tatsache, dass es eine minimale und maximale Heapgröße gibt, ergibt sich, dass der Heap zur Laufzeit wachsen oder schrumpfen kann. Wie sich die Heapgröße verändert, bestimmen die beiden Kommandozei-lenparameter -XX:MinHeapFreeRatio und -XX:MaxHeapFreeRatio. Die JVM versucht nämlich das Verhältnis von freiem Platz zu lebendigen Ob-jekten innerhalb eines gewissen Rahmens zu halten. Dieser Rahmen wird durch die oben erwähnten Parameter gesetzt. Setzt man die minimale und maximale Heapgröße auf den gleichen Wert, so ist die Größe des Heaps fix und kann sich nicht verändern.
Parameter, die die junge Generation betreffen
-XX:NewRatio
-NewSize
-MaxNewSize
-XX:SurvivorRatio
-XX:NewRatio bestimmt das Größen-Verhältnis zwischen der jungen und der alten Generation. Stellt man -XX:NewRatio beispielsweise auf den Wert 3, so ist das Verhältnis zwischen junger und alter Generation mit 1:3 festgelegt (der jungen Generation wird also ¼ der gesamten Heapgröße zugewiesen).
Die Werte NewSize und MaxNewSize legen die untere bzw. obere Grenze des newSpace fest. Genauso wie bei den Parametern –Xms und –Xmx kann man die Größe der jungen Generation fix festlegen, indem man die Werte NewSize und MaxNewSize auf den gleichen Wert setzt.
Die Größe von to und from (also den beiden Survi-vorSpaces) kann mit dem Parameter -XX:SurvivorRatio festgelegt werden. Setzt man diesen Wert beispielsweise auf 6, so beträgt das Verhältnis zwischen der nursery und einem survivorSpace 1:6 (das heißt die nursery ist acht mal so groß wie ein survivorSpace – nicht sieben mal so groß, da es ja zwei survivorSpaces gibt).
Links:
Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
Tool Report: GCViewer
Open Source Profilers in Java