Mit diesem Beitrag starten wir eine Reihe von Artikeln über das Memory Management in Java.  Wir beginnen mit den Prinzipien der Generational Garbage Collection, die von Suns JVM seit dem JDK 1.3 verwendet wird. Dabei wird der Heap-Speicher in unterschiedlichen Heap-Bereiche aufgeteilt. Dahinter steht die Idee, dass jeder der Heap-Bereiche die Objekte einer definierten Alterklasse enthält (deshalb der Name: Generational Garbage Collection).  Die Bereiche werden mit jeweils anderen Allokations- und Garbage-Collection-Algorithmen verwaltet werden. Dabei sind die Algorithmen speziell auf das Alter der Objekte optimiert.

Wir werden uns in den nächsten Artikeln unsere Kolumne mit automatischem Memory Management in Java sowie seinen Auswirkungen beschäftigen.  Dabei wird es um Speicherallokation und Speicherfreigabe gehen, aber auch um „Memory Leaks“, also unerwünschte Speicherverschwendung, Out-of-Memory-Probleme, unzumutbar lange Garbage-Collection-Pausen, Diagnose-Möglichkeiten, Tuning-Strategien und Compiler-Optimierungen wie Stack Allocation und Escape Analysis.  Motiviert ist die Artikelserie auch durch eine neue technologische Entwicklung in der Sun-JVM.  Die Speicherverwaltung ist immer komplexer geworden und seit Java 6 Update 14 gibt es einen radikal neuen Garbage Collector („Garbage First“, auch kurz „G1“ genannt), der in Java 7 als Standard-Garbage-Collector vorgesehen ist.  Wie funktioniert der neue Garbage Collector?  Was bringt er?  Welche Probleme löst er?

Ehe wir jedoch auf den neuen G1-Collector eingehen, wollen wir erst einmal die altbekannten Garbage Collectoren erläutern.  Der G1-Collector ist nämlich äußerst komplex und deshalb schwer zu verstehen, wenn man die Historie nicht kennt, aus der er sich entwickelt hat.  Außerdem werden uns die alten Collectoren noch eine ganze Weile begleiten und stehen als Alternative zu G1 auch in Java 7 weiterhin zur Verfügung.

Nun mag man sich die Frage stellen, wozu man sich als Java-Entwickler überhaupt mit der Speicherverwaltung in der virtuellen Maschine befassen sollte.  Solange es keine Probleme mit dem Anfordern und Freigeben von Speicher gibt, ist es in der Tat auch nicht erforderlich.  Wie aber die meisten aus der Praxis wissen, funktioniert nicht immer alles reibungslos. Bisweilen gibt es dann doch Probleme mit Speicherengpässen oder störenden Garbage-Collector-Pausen oder Performance-Probleme im Zusammenhang mit der Speicherverwaltung.  Es hilft dann bei der Diagnose und Problemlösung, wenn Kenntnisse über die Funktionsweise der Speicherverwaltung und des Garbage Collectors der virtuellen Maschine vorhanden sind.  Deshalb wollen wir das Thema „Speicherverwaltung in Java“ in der Artikelreihe näher beleuchten.

Wir beginnen die Artikelreihe mit den Prinzipien der sogenannten Generational Garbage Collection.   Warum wird der Speicher in „Generationen“ aufgeteilt?  Was sind diese Generationen?  Welche Generationen gibt es in der Sun JVM?
 

Generational Garbage Collection

Da man in Java (anders als beispielsweise in C++) keine Objekte auf dem Stack anlegen kann, müssen alle Objekte auf dem Heap alloziert werden. Selbst Objekte, die nur lokal in einer Methode gebraucht werden, entstehen auf dem Heap.  Die meisten dieser Objekte leben nicht lange: beim Verlassen der Methode werden sie bereits unerreichbar und sind damit „tot“.  Es gibt aber auch Heap-Objekte, die leben bis zum Ende der virtuellen Maschine, weil sie für die gesamte Ablaufzeit der Applikation gebraucht werden, zum Beispiel final static Attribute einer Klasse.

Insgesamt beobachtet man, dass die Objekt-Population eines typischen Java-Programms in etwa so aussieht, wie in Abbildung 1 gezeigt.
 
 

Es gibt sehr viele Java-Objekte, die nicht sehr alt werden, und es gibt vergleichsweise wenig Objekte, die sehr lange leben.  Die Objekte mit kurzer Lebensdauer sind die, die nur innerhalb einer Methode oder manchmal nur innerhalb einer Expression gebraucht werden.  Beispiele sind Iteratoren in einer Schleife oder StringBuilder fürs Zusammensetzen eines Strings.  Die Objekte mit mittlerer Lebensdauer sind solche, die in nicht-stackbasierten Verarbeitungen benutzt werden.  Ein Beispiel wäre der Conversational Session State einer Entity Bean.  Er überlebt mehrere Methodenaufrufe und wird erst nach der Session nicht mehr gebraucht.  Man beachte, die Zahl der Objekte mit mittlerer Lebensdauer ist deutlich geringer als die der kurzlebigen Objekte.  Richtig alt werden nur ganz wenige Objekte.  Das sind typischerweise Objekte, die schon beim Programmstart (oder per Lazy Evaluation etwas später) erzeugt werden und dann bis zum Ende der Anwendung in Gebrauch bleiben.  Dazu gehören Thread Pools, Singletons und Objekte aus Frameworks, z.B. Servlet-Instanzen.

Um den unterschiedlichen Objekt-Lebenszeiten angemessen Rechnung zu tragen, werden die Objekte verschiedenen Generationen zugeteilt.  Die Generationen sind separate Bereiche des Heaps, die unterschiedlich verwaltet werden.  Sie haben unterschiedliche Allokatoren und sie werden unterschiedlich oft und mit jeweils eigenen Garbage-Collection-Algorithmen aufgeräumt werden.  Im Wesentlichen unterscheidet man zwischen einer Young Generation, die häufig bereinigt wird, und einer Old Generation, die seltener bereinigt wird.  Die Young Generation ist der Speicherbereich, in dem die neuen Objekte angelegt werden, z.B. wenn im Programm mit new Speicher angefordert wird.  Die Old Generation ist der Bereich, in den die jungen Objekte ausgelagert werden, wenn sie ein gewisses Alter erreicht haben, d.h. wenn sie eine bestimmte Anzahl von Garbage Collections überlebt haben.

Warum ist es sinnvoll, dass die beiden Generationen unterschiedlich häufig und auch mit unterschiedlichen Algorithmen aufgeräumt werden? Dahinter steht die Beobachtung, dass von den jungen Objekten die meisten relativ schnell sterben, wie man in der Abbildung 1 gesehen hat, sodass in der Young Generation schnell viel Garbage entsteht.  Da, wo viel Garbage entsteht, lohnt sich zügiges Aufräumen, weil dann rasch wieder freier Speicher zur Verfügung steht.  Die Aufräumarbeiten auf die Young Generation zu beschränken, hat außerdem den Vorteil, dass nicht immer der gesamte Heap nach „toten“ Objekten durchforstet werden muss, sondern dass bereits das Aufräumen in einem Teilbereicht des Heaps signifikante Mengen an Speicher freigibt.
In der Old Generation lohnt sich das häufige Aufräumen nicht.  Wenn ein Objekt erst einmal mittelalt geworden ist, dann wird es mit hoher Wahrscheinlichkeit auch noch älter.  In der Old Generation findet man deshalb nicht so häufig „tote“ Objekte und damit weniger Potential für die Speicherfreigabe. Also macht man die Bereinigung der Old Generation wesentlich seltener.
Die Bereinigungen in der Young Generation werden als Minor Collections bezeichnet.  Daneben gibt es die seltener durchgeführten Major oder Full Collections, bei denen sowohl die Young als auch die Old Generation bereinigt wird. Diese Unterscheidung kann man bereits sehen, wenn man die virtuelle Maschine mit der Option –verbose:GC aufruft.  Die virtuelle Maschine gibt dann Information über die Garbage Collection aus (siehe Abbildung 2).
 
 

Man kann sehen, dass eine Full Garbage Collection selten durchgeführt wird, deutlich länger dauert als die Minor Garbage Collections, aber keineswegs mehr Speicher freischaufelt als eine Minor Garbage Collection.

Die Heapaufteilung in einer Sun-JVM

Perm-Space

Diese Non-Heap-Bereiche haben mit der Generational Garbage Collection nichts zu tun. Die Heap-Bereiche, in denen die Applikation ihre Objekte ablegt, sind die Young und die Old Generation.

Young Generation

Wenn nämlich im Rahmen einer Minor Garbage Collection überlebende Objekte in Eden und dem from-Space gefunden werden, so werden all diese überlebenden Objekte in den to-Space kopiert.  Danach steht der vormals belegte Speicher (Eden und der from-Space) als Ganzes wieder zur Verfügung.  Dabei wechseln from- und to-Space ihre Rollen.  Jetzt entstehen wieder Objekte in Eden, bis bei der nächsten Garbage Collection der Zyklus von vorne beginnt.

Ehe wir uns im nächsten Beitrag den Garbage-Collection-Algorithmus auf der Young Generation näher ansehen, werfen wir noch einen kurzen Blick auf die Old Generation.

Old Generation

Vor- und Nachteil der Generational Garbage Collection

Wie oben schon beschrieben, ist die Young Generation der Bereich, in dem viel alloziert und rasch gestorben wird.  Auf so einem Bereich ist es wichtig, dass Allokation und Garbage Collection schnell sind.  Auf der Old Generation wird wenig alloziert und selten gestorben, sodass die Geschwindigkeit der Algorithmen dort nicht so wichtig ist.  Alle Speicherverwaltungs-Algorithmen verursachen Kosten und Aufwände zu Lasten der Applikation.  Die Einteilung in Generationen ermöglicht es, die Prioritäten für die unterschiedlichen Bereiche spezifisch zu setzen.
Zu den Kosten gehört zum Beispiel: wie effizient geht ein Algorithmus mit dem Speicher um?  Wie wir im nächsten Beitrag sehen werden, brauchen die schnellen Allokations- und Garbage-Collection-Algorithmen auf der Young Generation relativ mehr Speicher als die langsamen Algorithmen auf der Old Generation.
Eine anderer Aspekt ist: wie sehr stört der Algorithmus meine Applikation?  Manche Garbage-Collection-Algorithmen müssen sämtliche Applikations-Threads stoppen, damit sie arbeiten können; das sind sogenannte Stop-the-World-Pausen, die äußerst störend sein können.  Es gibt andere Algorithmen, die können zumindest teilweise konkurrierend zur Applikation laufen und verursachen nur wenige kurze Pausen.

Wieder ein anderer Aspekt ist: wieviel Overhead erzeugt ein Algorithmus?  Manche Garbage-Collection-Algorithmen brauchen Unterstützung, sobald Referenzen gelesen oder verändert werden; das sind sogenannte Read- bzw. Write-Barriers.  So eine Barrier ist ein Stückchen Code, das bei Zugriffen auf Referenzen ausgeführt wird und dann irgendwas macht, was später der Allokations- oder der Garbage-Collection-Algorithmus braucht.  Das erzeugt zwar keine störenden Pausen, aber verlangsamt natürlich die Applikation insgesamt.  Manche Algorithmen hingegen kommen ganz ohne Barrier aus.

Die Einteilung in Generationen hat den Vorteil, dass man genau den Algorithmus wählen kann, der nach allen Kosten-Nutzen-Erwägungen am besten zum Alter der Objekte in der jeweiligen Generation passt.  Das setzt natürlich voraus, dass die Objektpopulation auch tatsächlich die erwarteten Eigenschaften hat.  In einem pathologischen Falle, wo die Applikation eben keine hohe „Kindersterblichkeit“ hat, wird die Generational Garbage Collection auch nicht so effizient sein.  Natürlich ist eine Generational Garbage Collection komplizierter und damit auch „teuerer“ als eine einfache Garbage Collection auf nur einem einzigen großen Heap mit nur einem einzigen Algorithmus.  Normalerweise werden die Kosten für die Komplikationen durch die Vorteile kompensiert.   Wie gesagt, in pathologischen Fällen kann es aber auch mal anders sein.

Wie der passende Algorithmus auswählt wird, hängt übrigens von der jeweiligen JVM-Implementierung ab.  Meistens sind die Aufteilung des Heaps und die Auswahl der Algorithmen in der JVM-Implementierung fest verdrahtet.  In gewissem Rahmen hat der Java-Anwender Einfluss, soweit eine JVM entsprechende Steuerungsmöglichkeiten über JVM-Optionen zur Verfügung stellt.  In der Sun-JVM gibt es zahllose Einstellschrauben, die wir im Verlauf dieser Artikelreihe zum Teil erwähnen werden.  Der Java-Anwender kann z.B. die Größe der Generation oder auch gewisse Details der Algorithmen einstellen.  Es gibt auch selbstadaptive Strategien, bei denen der Java-Anwender nur noch ein Ziel (minimaler Durchsatz oder maximale Pause) vorgibt, und die Garbage Collection stellt sich selbst so ein, dass das Ziel möglichst erreicht wird.  Das wird in der Sun-JVM als Garbage Collection Ergonomics bezeichnet.  Aber eine generelle Auswahl zwischen „Generational Garbage Collection – ja oder nein“ hat man in der Sun-JVM nicht.

Erst seit Java 6 Update 14 kann er alternativ zur Generational Garbage Collection den neuen (in Java 6 noch experimentellen) G1-Collector verwenden.
Wir werden ihn später ausführlich besprechen.  In den nächsten Beiträgen wollen wir aber erst einmal die Algorithmen auf der Young und der Old Generation erläutern, damit sich ein Java-Anwender im Falle von Problemen mit der Speicherverwaltung in Java 5 oder 6 überlegen kann, woran es wohl liegen könnte und was er tun könnte, um das Problem zu lösen.

Zusammenfassung

Literaturverweise

Die gesamte Serie über Garbage Collection:

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   High-Performance Java - programming, monitoring, profiling, and tuning techniques 4 day seminar ( open enrollment and on-site) Garbage Collection Tuning - profiling and tuning of memory related performance issues 1 day seminar ( open enrollment and on-site)