Garbage Collection sorgt bei Java 5.0 für frischen Wind

Es gibt zwei Performance-Kennzahlen für Java-Anwendungen (und besonders für Garbage Collection): Durchsatz und Pausen. Der Durchsatz ist hierbei der über einen längeren Zeitraum ermittelte prozentuale Zeitanteil, der nicht mit Garbage Collection verbracht wird. Der Durchsatz umfasst auch die Zeit für die Allokation (jedoch muss die Allokationsgeschwindigkeit im Allgemeinen nicht eingestellt werden). Pausen sind die Zeiten, während derer eine Anwendung nicht zu reagieren scheint, weil die Garbage Collection gerade im Gang ist.

Einige Nutzer ziehen noch andere Gesichtspunkte in betracht. So bezeichnet zum Beispiel der „Footprint“ die für einen Prozess notwendigen Ressourcen, die in Seiten und Cache-Zeilen gemessen werden. Bei Systemen mit begrenztem physischem Speicher oder zahlreichen Prozessen kann der „Footprint“ die Skalierbarkeit des Systems bestimmen. „Promptness“ bezeichnet die Zeit die zwischen dem „Tod“ eines Objekts und dem Verfügbarwerden des Speicherplatzes vergeht. Dies ist ein wichtiger Gesichtspunkt bei verteilten Anwendungen, einschließlich von RMI (Remote Method Invocation).

Im Allgemeinen wird mit der Größenfestlegung für eine Generation die Gewichtung dieser Gesichtspunkte bestimmt. So kann zum Beispiel eine sehr große Young-Generation den Durchsatz erhöhen, dies geht jedoch zu Lasten von „Footprint“, „Promptness“ und Pausenzeiten. Man kann die Pausen in der Young Generation minimieren, indem man auf Kosten des Durchsatzes eine kleine Young Generation verwendet.

Wenn die Leistung einer Anwendung mit einer größeren Anzahl an Prozessoren verbessert werden soll, ist es empfehlenswert den Throughput Collector einzusetzen. Man ruft den Throughput Collector mit der Befehlszeile flag -XX:+UseParallelGC auf. Die Zahl der Garbage Collector Threads kann mit der Befehlszeilenoption -XX:ParallelGCThreads=<gewünschte Anzahl> bestimmt werden. Die Ziele für die maximalen Pausenzeiten werden über die Befehlszeilenoption -XX:MaxGCPauseMillis=<nnn> festgelegt. Dieses interpretiert der Throughput Collector als Hinweis, dass Pausenzeiten von <nnn> Millisekunden oder weniger gewünscht sind. Es gibt zahlreiche Optionen zur Anpassung der Generationsgrößen, wie zum Beispiel -XX:YoungGenerationSizeIncrement=<nnn> für die Generation Young und -XX:TenuredGenerationSizeIncrement=<nnn> für die Generation Tenured.

Wenn eine Anwendung von kürzeren Pausen für die Garbage Collection profitiert und es sich erlauben kann, im Betrieb Prozessorressourcen mit dem Garbage Collector zu teilen, wäre der Concurrent Low Pause Collector angebracht. Es wird eine parallele Garbage Collection eingeleitet, wenn der „Füllstand“ der Tenured Generation über die Initialbelegung hinausgeht (also den Anteil am aktuellen Heap, der verwendet werden kann, bevor eine parallele Garbage Collection einsetzt). Die Initialbelegung wird standardmäßig auf ungefähr 68 Prozent gesetzt und kann mit dem Parameter -XX:CMSInitiatingOccupancyFraction=<nn> eingestellt werden, wobei <nn> einen prozentualen Größenanteil an der Generation Tenured repräsentiert. Man kann den Concurrent Collector so einsetzen, dass die parallelen Phasen inkrementell (schrittweise) ablaufen. Dieser Modus (der hier „i-cms“ genannt wird) verteilt die Arbeit, die der Collector parallel ausführt, auf kleine Zeitabschnitte, die zwischen die Collections in der Young Generation gelegt werden. Diese Funktion ist nützlich, wenn Anwendungen, die kurze Pausenzeiten verlangen, wie der Concurrent Collector sie ermöglicht, auf Rechnern mit wenigen Prozessoren laufen.