HotSpot ist eine unter dem Namen Java HotSpot Performance Engine veröffentlichte, sehr weit verbreitete Java Virtual Machine von Oracle (vorher von Sun Microsystems) für Arbeitsplatzrechner und Server. Sie basiert auf Techniken wie Just-in-time-Kompilierung und adaptiver Optimierung, um das Laufzeitverhalten von Software während der Ausführung zu verbessern.
| HotSpot | |
|---|---|
| Basisdaten
| |
| Maintainer | Oracle |
| Entwickler | Oracle |
| Erscheinungsjahr | 1999 |
| Aktuelle Version | 22 (12. Dezember 2011) |
| Betriebssystem | plattformübergreifend |
| Programmiersprache | C++, Assemblersprache |
| Kategorie | Java Virtual Machine |
| Lizenz | GNU General Public License |
| openjdk.java.net/groups/hotspot/ |
Entstehungsgeschichte Bearbeiten
Der Ursprung von HotSpot geht auf eine Gruppe von Programmierern zurück, die Anfang der 1990er-Jahre bei Sun Microsystems an der Programmiersprache Self gearbeitet hatten. Diese Programmierer Lars Bak, Gilad Bracha, Steffen Grarup, David Griswold, Robert Griesemer und Urs Hölzle verließen 1994 Sun und gründeten gemeinsam eine Firma namens Longview Technologies, die auch unter dem Namen Animorphic Systems auftrat, um dort die auf Smalltalk (Programmiersprache) basierte optional typisierte Programmiersprache Strongtalk zu entwickeln. Dort gelang Urs Hölzle die Entwicklung eines Type-Feedback-Compilers, und auch die Strongtalk-VM machte große Fortschritte. Aufgrund der stürmischen Entwicklung der neuen von Sun herausgebrachten Programmiersprache Java entschloss man sich eine grundlegend neue Java Virtual Machine zu entwickeln. In dieser Zeit wurde Srdjan Mitrovic aufgenommen, der für die Integration von Java in die neue VM sorgte. 1997 kaufte Sun Longview Technologies und Lars Bak wurde führender Ingenieur der Hotspot-VM bei Sun. Zum Zeitpunkt der Übernahme war HotSpot rund doppelt so schnell wie damals am Markt befindliche JVMs. Sun Microsystems seinerseits wurde 2010 von Oracle übernommen.
Überblick Bearbeiten
Der Sun Java Server (auch Opto oder C2) Compiler verwandelt den Java Bytecode der Java Virtual Machine (JVM) in ausführbaren Maschinencode der entsprechenden Zielplattform. Es handelt sich um einen hochoptimierenden Just-in-time-Compiler (JIT). Just-in-time-Compiler erzeugen den Maschinencode im Gegensatz zu Ahead-of-time-Compilern wie beispielsweise GCC erst zur Laufzeit des Programms. Damit schlägt der Übersetzungsvorgang selbst, neben der eigentlichen Laufzeit des Programms, in Form von CPU-Zyklen und längerer Laufzeit zu Buche. Da dieser (Kompilier-)Vorgang allerdings nur adaptiv, das heißt bei einigen Methoden (so genannten Hotspots) angewandt wird, dieser Aufwand einmalig und insbesondere bei langlaufenden Serveranwendungen sehr kurz verglichen mit der Programm-Ausführungszeit ist, wird dieser Mehraufwand schnell durch die höhere Qualität des erzeugten Maschinencodes kompensiert. Außerdem erfolgt die Kompilierung in einem gesonderten Thread, der auf SMP-Maschinen normalerweise auf einer gesonderten CPU ausgeführt wird.
Zu Beginn der Laufzeit eines Java-Programms wird der gesamte Bytecode ausschließlich interpretiert. Das geschieht in einer Interpreterschleife, die Bytecode für Bytecode abarbeitet. Die Besonderheit von Hotspot-Compilern liegt nun darin, nur häufig benutzte Codeabschnitte – so genannte „Hotspots“ – sukzessive in Maschinencode zu übersetzen. Die Hotspots werden unter anderem auch lokal, das heißt innerhalb von Methoden, entdeckt, die kleinste Kompiliereinheit ist aber in jedem Fall die Methode. Da die Übersetzung nur bei besonders häufig genutzten oder langlaufenden Methoden und nicht mit dem gesamten Code geschieht, ist der Mehraufwand speziell bei langlaufenden Anwendungen vernachlässigbar.
Der Vorteil dieses Verfahrens liegt in der Möglichkeit, Closed-world-Optimierungen durchzuführen sowie Dynamische Optimierungen anwenden zu können. Dies bedeutet, dass die JVM immer den gesamten geladenen Bytecode kennt und anhand dessen Optimierungsentscheidungen treffen kann, welche die Semantik des Codes so verändern, dass dieser nur mehr unter den vorhandenen Einsatzbedingungen korrekt funktioniert. Wird zur Laufzeit Code geladen, welcher diese Einsatzbedingungen ändert, so führt die (Server-)Hotspot-VM eine Deoptimierung durch – und garantiert somit die korrekte Funktion, indem es den für diesen Einsatz zu aggressiv optimierten Code entfernt und erneut optimiert.
Der Kompiliervorgang des Sun-Hotspot-Compilers setzt sich aus den folgenden Schritten zusammen:
Hotspot-Erkennung, Compile Policy Bearbeiten
Das grundsätzliche Verfahren, wie und unter welchen Umständen eine Methode übersetzt wird, wird in der Sun JVM durch so genannte CompilePolicies definiert. Diese in einer C++-Klassenhierarchie modellierten Richtlinien sind im Fall des Server-Compilers in der Klasse StackWalkCompPolicy gespeichert. Somit kann durch Wechseln beziehungsweise Anpassen der Richtlinien der Kompiliervorgang umkonfiguriert werden. Das kommt in der Praxis allerdings relativ selten vor, vom Setzen des Flags -XX:+CompileTheWorld zum Übersetzen buchstäblich aller Methoden einmal abgesehen. Der Name StackWalkCompPolicy geht auf den Algorithmus zurück, den Aufrufstack der zu untersuchenden Methoden solange nach oben zu prüfen, bis die erste Methode entdeckt wird, die nicht mehr zu einem Inlining führen wird.
Im Servercompiler werden zur Erkennung der Hotspots zwei Schwellwerte herangezogen:
Im Servercompiler befinden sich bereits Vorkehrungen, in späteren Versionen eine so genannte Two-tier-Kompilierung zu unterstützen. Dabei geht es darum, eine Methode zuerst zügig und ohne massive Optimierung zu kompilieren und später (oder parallel) in einem weiteren Durchlauf hochoptimiert zu übersetzen. Diese „two tier compilation“ wird perspektivisch zu einer Verschmelzung von Server und Client-Compiler führen.
Kompilierung Bearbeiten
Nachdem die Policy-Steuerung einzelne Methoden nun zum Kompilieren markiert hat, wird für jede der Methoden ein CompileTask Object erzeugt und in die CompileQueue eingereiht. Das, sowie die sonstige Kontrolle des gesamten Übersetzungsvorgangs, obliegt dem CompileBroker. Dieser erzeugt die einzelnen Übersetzungsjobs (CompileTask), stellt sie in die Queue und weckt zuletzt mit einem notify() inaktive Compile Threads. Die Anzahl der Compile Threads ist im Normalfall log(Anzahl der CPUs), doch mindestens zwei. Im CompileBroker werden auch diverse PerfCounter-Objekte gehalten, die zur späteren Leistungsüberwachung beziehungsweise -anzeige herangezogen werden können.
Nun wird der Bytecode in verschiedenen Phasen umgewandelt. Die wichtigsten Schritte sind hierbei:
- Parsen des Bytecodes
- Löschen ungenutzter Knoten (nodes)
- Auswählen der Instruktionen.
- Global Value Numbering (GVN)
- Control Flow Graph (CFG) erzeugen
- Register Allocation (Chaitin Graph Coloring)
- Peephole-Optimierung
Die Internal Representation (IR) des Programmlaufs wird im SSA-Format gespeichert.
Optimierung Bearbeiten
Unter anderem durch die Speicherung des Knoten-Graphs im SSA-Format ist es möglich, eine Reihe von Optimierungsverfahren anzuwenden. Hier die wichtigsten:
Codegenerierung, Aktivierung Bearbeiten
AD-Dateien Bearbeiten
Der Codegenerator (Emitter) des Systems erzeugt Maschinencode auf der Basis von vorgefertigten Schablonen, die zu dem Bytecode korrespondierende Assemblercodestrecken in so genannten Architecture Description Files (AD-Dateien) speichern. In diesen Dateien werden die verschiedenen CPUs abstrakt mit ihren Assemblerbefehlen, Adressiermodi und besonders der Anzahl und Breite der Register beschrieben. Die AD-Dateien werden mittels eines speziellen Preprozessors in C++-Klassen übersetzt, die in den VM-Buildprozess einfließen.
CompileCache Bearbeiten
Die von dem Compiler erstellten Assemblersprache-Instruktionen werden im CompilerCache mit einer Referenz auf den ursprünglichen Bytecode abgelegt. Das ist notwendig, um bei einer späteren Deoptimierung wieder auf den Bytecode zugreifen zu können. Deoptimierung kann nötig werden, wenn etwa dynamisch geladene Klassen, in denen einzelnen Methoden eingebettet wurden (Inlining), zur Laufzeit durch neue ersetzt werden.
Stubs Bearbeiten
Der durch den Kompiliervorgang erzeugte Maschinencode kann ohne Inanspruchnahme von Services der VM nicht funktionieren. In einer Methode muss zum Beispiel immer wieder ein name lookup in der Symboltabelle vorgenommen, eine Referenz aufgelöst oder andere Dienstleistungen der JVM in Anspruch genommen werden. Deswegen werden in den Maschinencode immer wieder so genannte Stubs eingefügt, durch die der kompilierte Code quasi Kontakt zur Außenwelt aufnimmt.
Aktivieren des Kompilats Bearbeiten
Grundsätzlich kann die fertiggestellte Methode entweder zur Laufzeit des Bytecodes ausgetauscht oder aber zum Zeitpunkt des nächsten Aufrufs verwendet werden. Das Unterbrechen einer laufenden Methode und Austauschen gegen die kompilierte Version nennt man On-Stack-Replacement (OSR). Um diese hochdynamische Operation zu bewerkstelligen, werden im Bytecode so genannte Savepoints eingefügt. An diesen Savepoints befindet sich die Virtual Machine in einem definierten, synchronisierten Zustand. Nun wird der Bytecode gegen das Kompilat getauscht und der genau entsprechende CPU-Stack synthetisch erzeugt.
Literatur Bearbeiten
- Michael Paleczny, Christopher Vick, Cliff Click: The Java HotSpot server compiler. In: Proceedings of the Java Virtual Machine Research and Technology Symposium on Java Virtual Machine Research and Technology Symposium - Volume 1. USENIX Association, Monterey, California 2001 (acm.org).
- Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman: Compiler. Principles, Techniques, and Tools. Addison-Wesley, Reading 1988, ISBN 0-201-10194-7 (das „Dragon Book“).
Quellen Bearbeiten
- 27. April 1999 (abgerufen am 2. November 2013).
- The hotspot Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 18. Juli 2018).
- The Java HotSpot Performance Engine Architecture. Abgerufen am 9. Juni 2020.
- The History of the Strongtalk Project von Dave Griswold.
- Sun buys Java compiler technology based upon Self!!! Keith Hankin 18. Februar 1997
- (Memento vom 20. April 1999 im Internet Archive), Mountain View 18. Februar 1997
- Google 'Crankshaft' inspired by Sun Java HotSpot – Bak to 'adaptive compilation' von Cade Metz, 9. Dezember 2010
- (Memento des vom 23. September 2015 im Internet Archive) Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. von Lars Bak
Weblinks Bearbeiten
- Michael Paleczny, Christopher Vick, Cliff Click: The Java HotSpot Server Compiler. Sun Microsystems (PDF-Datei, 111 kB, englisch)
- Sun Barcelona Virtual Machine (englisch)
- Java Virtual Machine Specification (englisch)
- Java SE HotSpot at a Glance (englisch)