Das 1x1 der Müllsammlung

Neuer Garbage Collector in Java 9: Was ändert sich – was bleibt?

Uwe Schindler

(c)  Shutterstock / grethen.tal

Oracle hat mit der Entscheidung, das JDK Enhancement Proposal (JEP) 248 in seine Liste der für Java 9 vorgesehenen Features aufzunehmen und damit den Garbage-First (G1) Collector zum Standard-Garbage Collector für Server-Konfigurationen zu machen, für einige Diskussionen in der Java-Community gesorgt. Doch wo liegen die Unterschiede zwischen G1 und dem aktuellen ParallelGC? Welchen Handlungsbedarf gibt es für alle zukünftigen Nutzer von Java 9?

Das 1×1 der Müllsammlung

Garbage Collection hat einige Nachteile, welche sich je nach Anwendungszenario negativ auf eine Applikation auswirken können. Das liegt darin begründet, dass das Müllsammeln selbst Ressourcen kostet und damit auch die laufende Anwendung beeinflusst. Das kann man im Vergleich mit der realen Welt sehr einfach verstehen: Je mehr Müll sich angestaut hat und je größer die Stadt ist, desto länger braucht die Müllabfuhr, um diesen wegzuräumen und zu verwerten.

In der Java-Welt ist das genauso. Je größer die Heap-Size moderner Applikationen wird, desto mehr Zeit wird damit verschwendet, unreferenzierte Java-Objekte zu finden und aufzuräumen. Wenn dabei plötzlich die gesamte Anwendung für teilweise mehrere Minuten anhält, dann ist das ein K.O.-Kriterium. Im Laufe der Zeit wurden daher die Algorithmen, welche das Einsammeln, Aufräumen und Wegwerfen der Objekte implementieren, daraufhin optimiert, nicht so stark auf dem Programmablauf einzuwirken.

Der Entwickler hat dabei die Auswahl zwischen mehreren Algorithmen. Wenn man jedoch keinen angibt, wird der standardmäßige benutzt. Dieser arbeitet zwar parallel zum eigentlichen Programmablauf, es gibt aber trotzdem ab und zu Phasen, in denen dieser für das endgültige Aufräumen (Entfernen der toten Objekte und Defragmentierung) alle laufenden Java Threads anhalten muss. Dies wird als Stop-The-World (STW) bezeichnet. Je nach Größe und Anzahl der Objekte auf dem Heap kann dies manchmal sehr lange dauern. Und das passiert natürlich genau dann, wenn man es am wenigsten brauchen kann.

Garbage First?

Der für Java 9 vorgeschlagene neue Garbage Collector G1 (Garbage First, G1GC) ist bereits seit Java 7u4 bei der JDK mitgeliefert, wird aber nicht automatisch ausgewählt. G1 spaltet das Aufräumen der “Old Generation” (langlebige Objekte) in mehrere Phasen auf, die jedoch nicht alle Stop-The-World sein müssen. Dadurch werden die Pausen kürzer und das Programm kann dazwischen wieder weiterlaufen.

Leider hat dies zur Folge, dass der Verwaltungaufwand größer wird, und da ja das ganze Programm nicht steht, muss dafür Sorge getragen werden, dass die Bedingungen für die Sichtbarkeit von Objekten (das Java Memory Model) während der Aufräumaktionen nicht verletzt werden. Das erfordert zusätzliche Synchronisation (Memory Barriers), welche die Ausführungsgeschwindigkeit verringern. Für Web-Anwendungen ist es jedoch meistens kein Problem, wenn dafür aber keine so langen STW-Pausen mehr auftreten.

G1 versus ParallelGC

Nach der Ankündigung Oracles, G1 zum Standard-Garbage-Collector in Java 9 zu machen, wird das Thema auf der Mailing-Liste lebhaft diskutiert. Die Befürworter von G1 preisen natürlich die oben genannten Eigenschaften des G1GC an. Dieser Garbage Collector hat gegenüber dem derzeitigen Standard (dem ParallelGC) natürlich einige Vorteile! Allem voran ist dies die Garantie, dass die STW-Pausen des GC (wenn möglich) unterhalb einer bestimmten Zeit liegen. Für heutige Anwendungen wie Webserver mit hoch dynamischen, REST-basierten JavaScript-Anwendungen, welche auf kurze Antwortzeiten des Backendservers angewiesen sind oder Suchmaschinen für Online Shops, welche sehr kurze Antwortzeiten benötigen (Apache Solr / Elasticsearch), ist dies wirklich sinnvoll.

Allerdings muss man die Diskussion auf der Mailingliste auch unter folgenden Gesichtspunkten betrachten: Der G1GC wurde ursprünglich als Ersatz für den heute in vielen Anwendungen verwendeten Concurrent Mark Sweep (CMS) Collector angepriesen. Dieser ist jedoch nicht der Standard in Java 7 oder Java 8! Viele der Vergleiche hinken daher etwas, weil der standardmäßige ParallelGC sich anders verhält und bei diesem die Pausen deutlich länger sind und daher die Vorteile des G1GC überwiegen.

In der Diskussion wurde daher ein gerechtfertigter Punkt u.a. auch von Google aufgebracht: Google hat in seinen Datenzentren einen modifizierten CMS Collector, welcher sich angeblich besser verhält als G1GC. Das führt dazu, dass einige der Diskutierenden es für angemessener halten, doch lieber den schon vielfach erprobten CMS als Standard für Java 9 auszuwählen!

G1 und Apache Lucene

Apache Lucene testet seit Jahren die Volltextsuchmaschine mit zahlreichen Versionen der Oracle JDK. Dies wurde nach den Problemen eingeführt, welche bei der Veröffentlichung von Java 7 auftraten. Dadurch wurden viele Fehler aufgedeckt, auch in den verschiedenen Müllsammlern. Leider treten in den Dauertests ab und an Probleme mit dem G1GC auf, z.B. stirbt die virtuelle Maschine während der Testdurchläufe oder erzeugte Lucene-Indexe sind defekt, weil es zu Berechnungsfehlern beim Schreiben der Daten kommt.

Der Grund für diese Probleme liegt in der erhöhten Komplexität des G1GC, welcher tiefer in die Strukturen der Hotspot-VM eingreift. Aufgrund der erhöhten Parallelität des G1 sind mehr Memory Barriers im VM-Code notwendig, um das Java Memory Model einzuhalten. Und genau hier kommt es ab und an zu Problemen. Aus diesem Grund empfehlen die Lucene- und Elasticsearch-Entwickler, G1GC derzeit nicht zu benutzen. Dies war auch Bestandteil der Diskussion über JEP 248.

Andererseits arbeitet Oracle sehr viel am G1, um noch mehr Geschwindigkeit und vor allem Fehlerfreiheit zu garantieren. Bei der Beobachtung der Lucene Builds in den letzten Monaten haben wir festgestellt, dass die anfänglich gefundenen Fehler nicht mehr aufgetreten sind. Das deckt sich auch mit der Aussage von Oracle, dass G1GC ab Java 8 Update 40 “produktionsreif” ist. Allerdings beschleicht einen immer noch ein mulmiges Gefühl, denn einige der Fehler wurden bis heute nicht verstanden; sie treten einfach nicht mehr auf – mehr weiß man nicht. Bis zur Veröffentlichung von Java 9 dürfte sich aber noch viel ändern.

Handlungsbedarf?

In Java 9 wird der Garbage Collector standardmäßig wohl auf G1GC gesetzt werden. Die meiste Software, welche im Umlauf ist, setzt aber den Garbage Collector sowieso explizit, z.B. haben dies viele Application Server im Startup-Skript stehen, genauso auch Apache Solr oder Elasticsearch. Solche Produkte werden daher nicht automatisch von einer Änderung des Default-GC beeinflusst. Alles bleibt also beim Alten! Genauso sicher ist es, dass Software, die heute schon den G1GC explizit benutzt, auch weiterhin laufen wird!

Kurzum: Für Anwender von Java besteht kein Grund zur Sorge, da der Großteil der auf dem Markt befindlichen Software ohnehin die Garbage Collection festlegt, wodurch sich bei einem Update keine Änderungen ergeben würden. Man kann JEP 248 daher eher als ein Signal an die Hersteller solcher Software verstehen, sich mit dem Thema zu beschäftigen und auch vielleicht schon für das derzeit verfügbare Java 8 Update 45 in ihren Produkten den G1GC zu aktivieren. Es spricht aber auch nichts dagegen, den Concurrent Mark Sweep Collector weiterhin explizit zu benutzen.

Aufmacherbild:  Separate waste collection von Shutterstock / Urheberrecht: grethen.tal

Verwandte Themen:

Geschrieben von
Uwe Schindler
Uwe Schindler
Uwe Schindler ist Mitglied des Project Management Committee im Apache-Lucene-Projekt. Er ist mit seiner Consulting-Firma SD DataSolutions GmbH in Bremen ansässig und kümmert sich am Zentrum für Marine Umweltwissenschaften (MARUM) um die Suche nach geowissenschaftlichen Daten in der Umweltdatenbank PANGAEA.Blog: http://blog.thetaphi.deTwitter: @ThetaPh1
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Neuer Garbage Collector in Java 9: Was ändert sich – was bleibt?"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

Ja, auch wir hatten kleine Schwierigkeiten mit dem G1 Collector. Eclipse stürzte sporadisch ab. Mit dem CMS Collector passiert das nicht. Ich hoffe, Oracle bekommt den G1 Collector in den Griff. Der ist nämlich zumindest auf dem Papier sehr gut.

Grüße