Garbage Collection sorgt bei Java 5.0 für frischen Wind

Das Ziel einer neuen Funktion in Java 1.5 namens ergonomics besteht darin, eine gute Leistung der JVM [Java Virtual Machine] zu erreichen und dabei die Befehlszeilen so wenig wie möglich verändern zu müssen. Ergonomics versucht, die beste Kombination von Garbage Collector, Datenaufkommen und Runtime Compiler für eine jeweilige Anwendung zusammenzustellen.

Wann hat die Auswahl des Garbage Collectors Auswirkungen für den Nutzer? Bei vielen Anwendungen gibt es keinen Unterschied. Die Anwendungen können dann innerhalb ihres Leistungsbereichs arbeiten, obwohl durch die Garbage Collection in gewissen Abständen Pausen kurzer Dauer entstehen. Ein Beispiel, wo dieses nicht der Fall ist, wäre eine große Anwendung, die eine große Zahl von Threads, Prozessoren und viel Speicher in Anspruch nimmt.

Ein Objekt wird als Garbage (Müll) betrachtet, wenn es von keiner Stelle im laufenden Programm mehr angesteuert werden kann. Die elementarsten Garbage Collection-Algorithmen gehen einfach alle erreichbaren Objekte durch. Alle verbleibenden Objekte werden danach als Garbage betrachtet. Die hierfür benötigte Zeit verhält sich proportional zur Anzahl der aktiven Objekte, wodurch das Verfahren bei großen Anwendungen mit vielen aktiven Datenobjekten ungeeignet ist.

Seit Java 2 enthält die Virtual Machine eine Anzahl verschiedener Garbage-Collection-Algorithmen, die über eine generationelle Garbage Collection (GC mit Einteilung der Objekte in verschiedene Altersklassen) kombiniert werden. Während bei einfacher Garbage Collection jedes aktive Objekt im Speicher überprüft wird, nutzt die generationelle GC mehrere empirisch ermittelte Eigenschaften der meisten Anwendungen, um zusätzliche Arbeit zu vermeiden. Die wichtigste der überprüften Eigenschaften ist die so genannte „Infant Mortality“ (Säuglingssterblichkeit). Es gibt viele Objekte, die bereits kurz nach der Speicherzuweisung „tot“ sind. Iterator-Objekte zum Beispiel sind oft nur einen Durchlauf lang aktiv. Um unter diesen Bedingungen eine optimale Speicherverwaltung zu ermöglichen, werden die Objekte in Altersklassen oder Speicherpools eingeteilt, die Objekte der unterschiedlichen Altersklassen enthalten. Garbage Collection findet jeweils statt, wenn der Speicher einer Klasse voll ist. Die Objekte werden zunächst der Altersgruppe „Young“ [Younger Objects, Young Generation] zugewiesen, wobei die meisten aufgrund der „Infant Mortality“ nicht in eines der älteren Segmente aufsteigen.

Wenn der Garbage Collector zum Engpass wird, möchte man unter Umständen die Speicherkapazität der Generationen anpassen. Man überprüft die Ergebnisse der Garbage Collection mit der Option -verbose und untersucht, inwieweit die eigenen Performance-Anforderungen mit den Einstellungen des Garbage Collectors korrelieren.

Bei der Initialisierung wird virtuell ein maximaler Adressbereich reserviert, jedoch nicht im physischen Speicher zugewiesen, bevor er benötigt wird. Der gesamte Adressbereich, der für die Speicherung von Objekten reserviert ist, kann in junge und ältere Generationen eingeteilt werden. Die Generation „Young“ besteht aus einem Eden genannten Bereich und zwei so genannte „Survivor Spaces“. Die Allokation von Objekten findet in Eden statt. Es ist immer ein Survior Space frei, der zur Aufnahme der nächsten Sammlung aktiver Objekte aus Eden und dem anderen Survivor Space dient. Objekte werden auf diese Weise so lange zwischen den Survior Spaces hin und her verschoben, bis sie alt genug sind, um in die nächste Generation („Tenured“) verschoben oder kopiert zu werden. Eine dritte, eng mit der Generation „Tenured“ verbundene Generation ist die Generation „Permanent“. Diese Generation nimmt eine Sonderstellung ein, da sie Daten enthält, die von der Virtual Machine benötigt werden, um Objekte zu beschreiben, für die es auf der Java-Sprachebene keine Entsprechung gibt. So werden zum Beispiel Objekte, die Klassen und Methoden beschreiben, in der Generation „Permanent“ gespeichert.