infaktum Veranstaltungen

[ruhrjug] Während der Sommerferien ist es ja normalerweise schon etwas leerer in den Büros und auf den Straßen, und so waren wir dann doch überrascht, als zur August-Veranstaltung der ruhrjug über 70 Besucher kamen. Trotz Nachbestellung war unser Sandwich-Buffet sehr schnell leergeräumt… (bis auf viel "Garbage")

Die Garbage Collection

Im Mittelpunkt des Abends stand die Garbage Collection in der JVM; ein Thema, womit sich die meisten Java-Entwickler kaum beschäftigen, da die GC für ihn ja transparent sein soll. Doch lassen sich manchmal Performance-Probleme durch passende Justierung der GC beheben, etwa mangelnder Durchsatz oder auch spürbare Pausen bei der Benutzer-Interaktion.

Young and Old Generation

Zuerst erklärte Angelika Langer das Prinzip der „alten“ Garbage Collection in der JVM bis etwa Version 1.5. Schon in dieser Version haben sich die JVM-Designer einige Gedanken gemacht über die Lebenszyklen von Objekten im Heap, um die GC zu optimieren. So wurde der Heap in mehrere Bereiche unterteilt:

Eden, wo neue Objekte erzeugt werden, und wo die meisten Objekte auch wieder sterben, da sie nur lokal verwendet werden. Zwei Survivor-Bereiche, in dem die Überlebenden der GC im Eden-Bereich landen, und schließlich den Bereich der „alten“ Objekte, die über längere Zeit in der Applikation verwendet werden. Für die einzelnen Bereiche gibt es verschieden optimierte Strategien.

Um nun die GC an individuelle Bedürfnisse der Applikation anzupassen, ist es möglich, diese Bereiche verschieden groß einzustellen. Dies ist ein Trial-and-Error-Prozess, und es gibt da kein Patentrezept. Darüber hinaus muss man lassen sich nicht Durchsatz (d.h. Anteil der Zeit, die die JVM im eigentlichen Programm zubringt) und Pausenminimierung gleichzeitig optimieren. Immerhin gibt es verschiedene Monitoring-Tools, die einen bei dieser Feinabstimmung unterstützen. Außerdem unterstützt die GC mittlerweile auch Multi-threading.

Garbage First

Danach stellte Klaus Kreft die neue Garbage Collection G1 vor (für „Garbage first“), die in den neuen Java-Versionen zur Verfügung steht. Hier hat SUN weitere Optimierungen vorgenommen; so wird der Speicher nicht mehr in feste Bereiche für die GC unterteilt; stattdessen wird dieser synamisch für junge unt alte Objekte aufgeteilt. Der Entwickler kann nun mit zwei Parametern die GC steuern, dem minimalen Zeitintervall zwischen zwei GCs sowie der maximalen Dauer einer GC. Der Garbage Collector versucht weitestgehend, diese Constraints einzuhalten, indem er die GC nicht auf den ganzen Heap anwendet, sondern nur auf Blöcken (Collections) arbeitet. Während einer GC versucht er, so viele Blöcke wie möglich zu verarbeiten (zuerst junge, dann ältere). Dabei entsteht allerdings ein teils erheblicher Overhead durch Bookkeeping-Aufgaben. Auch hier ist eine Feinabstimmung notwendig, wobei es leider noch keine komfortablen Monitoring-Tools gibt; man ist auf den Konsolen-Output angewiesen.

Fazit

Für die Optimierung der Garbage Collection gibt es kein Patentrezept, und auch keine perfekte Lösung., was in der Natur der Sache liegt. Trotzdem lassen sich mitunter enorme Performanz-Gewinne durch Drehen der vorhandenen Stellschrauben erzielen, wobei es einiges an Tool-Unterstützung gibt.

Einen Artikel von Angelika Langer zum Thema findet man hier >>>

Ein paar Bilder...