imported>Jule Glühwurm: /* growthexperiments-addlink-summary-summary:2|0|0 */

2025-03-20T13:47:04Z

growthexperiments-addlink-summary-summary:2|0|0

Neue Seite

{{Dieser Artikel|behandelt eine Java Virtual Machine; zu weiteren Bedeutungen siehe [[Hot Spot]].}}
{{Infobox Software
| Logo =
| Screenshot =
| Beschreibung = 
| Maintainer = [[Oracle]]
| Hersteller = [[Oracle]]
| Management =
| AktuelleVersion = 22
| AktuelleVersionFreigabeDatum = 12. Dezember 2011
| AktuelleVorabVersion =
| AktuelleVorabVersionFreigabeDatum =
| Betriebssystem = [[plattformübergreifend]]
| Programmiersprache = 
| Kategorie = [[Java Virtual Machine]]
| Lizenz = 
| Deutsch =
| Website = 
}}

'''HotSpot''' ist eine unter dem Namen '''Java HotSpot Performance Engine'''<ref>{{Internetquelle |url=https://www.oracle.com/technetwork/java/whitepaper-135217.html |titel=The Java HotSpot Performance Engine Architecture |abruf=2020-06-09}}</ref> 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 [[Adaptive Optimierung|adaptiver Optimierung]], um das Laufzeitverhalten von Software während der Ausführung zu verbessern.

== Entstehungsgeschichte ==

Der Ursprung von HotSpot geht auf eine Gruppe von Programmierern zurück, die Anfang der 1990er-Jahre bei [[Sun Microsystems]] an der Programmiersprache [[Self (Programmiersprache)|Self]] gearbeitet hatten. Diese Programmierer [[Lars Bak (Informatiker)|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 [[Optionale Typisierung|optional typisierte]] Programmiersprache [[Strongtalk]] zu entwickeln. Dort gelang Urs Hölzle die Entwicklung eines Type-Feedback-Compilers, und auch die Strongtalk-[[Virtuelle Maschine|VM]] machte große Fortschritte.<ref name="ST-History">[http://strongtalk.org/history.html The History of the Strongtalk Project] von Dave Griswold.</ref> Aufgrund der stürmischen Entwicklung der neuen von Sun herausgebrachten Programmiersprache [[Java (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<ref>[http://www.merlintec.com/old-self-interest/msg01011.html Sun buys Java compiler technology based upon Self!!!] Keith Hankin 18. Februar 1997</ref> Longview Technologies<ref>{{Webarchiv |url=http://java.sun.com/pr/1997/feb/pr970218-01.html |text=Engineers to make significant contributions to Sun's Java Platform |wayback=19990420194046}}, [[Mountain View (Santa Clara County, Kalifornien)|Mountain View]] 18. Februar 1997</ref> 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.<ref>[http://www.theregister.co.uk/2010/12/09/google_crankshaft_and_sun_java_hotspot/ Google 'Crankshaft' inspired by Sun Java HotSpot – Bak to 'adaptive compilation'] von Cade Metz, 9. Dezember 2010</ref><ref>{{Webarchiv |url=http://www.aosd.net/2012/images/stories/bak.pdf |text=Language Based Virtual Machines … or why speed matters |wayback=20150923172541 |archiv-bot=}} von Lars Bak</ref>
Sun Microsystems seinerseits wurde 2010 von [[Oracle]] übernommen.

== Überblick ==
Der Sun Java Server (auch Opto oder C2) [[Compiler]] verwandelt den [[Java (Programmiersprache)|Java]] [[Bytecode]] der [[Java Virtual Machine]] (JVM) in ausführbaren Maschinencode der entsprechenden Zielplattform. Es handelt sich um einen hochoptimierenden [[Just-in-time-Kompilierung|Just-in-time-Compiler]] (JIT). Just-in-time-Compiler erzeugen den Maschinencode im Gegensatz zu [[Ahead-of-time-Compiler]]n wie beispielsweise [[GNU Compiler Collection|GCC]] erst zur Laufzeit des Programms. Damit schlägt der Übersetzungsvorgang selbst, neben der eigentlichen Laufzeit des Programms, in Form von [[Hauptprozessor|CPU]]-Zyklen und längerer Laufzeit zu Buche. Da dieser (Kompilier-)Vorgang allerdings nur adaptiv, das heißt bei einigen [[Methode (Programmierung)|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 (Informatik)|Thread]]'', der auf [[Symmetrisches Multiprozessorsystem|SMP]]-Maschinen normalerweise auf einer gesonderten CPU ausgeführt wird.

Zu Beginn der Laufzeit eines [[Java (Programmiersprache)|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 Optimierung]]en 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 ==
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 <code>StackWalkCompPolicy</code> 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 <code>-XX:+CompileTheWorld</code> 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:
;Aufrufhäufigkeit einer Methode: Dieser Schwellwert wird in der JVM-internen [[Variable (Programmierung)|Variable]] ''CompileThreshold'' gehalten und hat auf den verschiedenen Plattformen unterschiedliche Grundeinstellungen. Auf der [[IA-32|Intel-386-Architektur]] sind es bei der Server-JVM 10.000 und bei der Client-JVM 1.500 Methodenaufrufe.
;Anzahl von Schleifendurchläufen in einer Methode: Werden Schleifen in Methoden allzu häufig durchlaufen, markiert dies eine Methode ebenfalls zur Kompilierung. Die Häufigkeit eines Schleifendurchlaufs wiederum wird in so genannten ''Backedge-Countern'' für jede Schleife einzeln mitgezählt.

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 ==
Nachdem die Policy-Steuerung einzelne Methoden nun zum Kompilieren markiert hat, wird für jede der Methoden ein <code>CompileTask</code> Object erzeugt und in die <code>CompileQueue</code> eingereiht. Das, sowie die sonstige Kontrolle des gesamten Übersetzungsvorgangs, obliegt dem <code>CompileBroker</code>. Dieser erzeugt die einzelnen Übersetzungsjobs (<code>CompileTask</code>), stellt sie in die Queue und weckt zuletzt mit einem <code>notify()</code> inaktive Compile Threads. Die Anzahl der Compile [[Thread (Informatik)|Threads]] ist im Normalfall log(Anzahl der CPUs), doch mindestens zwei. Im CompileBroker werden auch diverse <code>PerfCounter</code>-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 [[Static Single Assignment|SSA]]-Format gespeichert.

== Optimierung ==
Unter anderem durch die Speicherung des Knoten-Graphs im SSA-Format ist es möglich, eine Reihe von Optimierungsverfahren anzuwenden. Hier die wichtigsten:

;Inlining: Kurze Methoden (maximal 35 [[Byte]]s) werden in den Rumpf des Aufrufers eingefügt, anstatt angesprungen zu werden. Bei längeren Methoden rentiert sich Inlining nicht.

;Loop-Unrolling: Kurze Schleifen werden sozusagen „entrollt“, das heißt, die einzelnen Schleifendurchläufe werden sequenziell ohne Rücksprung abgearbeitet. Das vergrößert ähnlich dem Inlining den Speicherverbrauch, ist aber bei wenigen Schleifendurchläufen billiger als das ständige Testen einer Sprungbedingung.

;Dead Code Elimination: Ungenutzte Anweisungen werden auf Bytecodeebene entdeckt und verworfen. Obwohl diese Optimierung auf Quellcodeebene durch den ''[[Java (Programmiersprache)|Java]] Frontend Compiler'' (javac) weit mehr Anwendung findet, wird dieser Schritt auch auf Bytecodeebene angewendet.

;Peephole-Optimierung: Optimierung auf Assemblerebene. Hierbei wird ein Kontext (''peephole'') über einige wenige Assembler-Instruktionen erzeugt und zum Beispiel redundante Speicherzugriffe eliminiert und Registerzugriffe optimiert.

== Codegenerierung, Aktivierung ==
=== AD-Dateien ===
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 ===
Die von dem Compiler erstellten [[Assemblersprache]]-Instruktionen werden im <code>CompilerCache</code> 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 ===
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 [[Stub (Programmierung)|Stubs]] eingefügt, durch die der kompilierte Code quasi Kontakt zur Außenwelt aufnimmt.

== Aktivieren des Kompilats ==
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 ==
* {{Literatur
|Autor=Michael Paleczny, Christopher Vick, Cliff Click
|Titel=The Java HotSpot server compiler
|Sammelwerk=Proceedings of the Java Virtual Machine Research and Technology Symposium on Java Virtual Machine Research and Technology Symposium
|Band=Vol. 1
|Verlag=USENIX Association
|Ort=Monterey, California
|Datum=2001
|Online=http://portal.acm.org/citation.cfm?id=1267848}}
* {{Literatur
|Autor=Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman
|Titel=Compiler. Principles, Techniques, and Tools.
|Verlag=Addison-Wesley
|Ort=Reading
|Datum=1988
|ISBN=0-201-10194-7
|Kommentar=das „Dragon Book“}}

== Quellen ==
<references />

== Weblinks ==
* Michael Paleczny, Christopher Vick, Cliff Click: ''[http://www.usenix.org/events/jvm01/full_papers/paleczny/paleczny.pdf The Java HotSpot Server Compiler.]'' Sun Microsystems (PDF-Datei, 111 kB, englisch)
* [http://labs.oracle.com/projects/barcelona/ Sun Barcelona Virtual Machine] (englisch)
* [http://docs.oracle.com/javase/specs/jvms/se5.0/html/VMSpecTOC.doc.html Java Virtual Machine Specification] (englisch)
* [http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html Java SE HotSpot at a Glance] (englisch)

[[Kategorie:Java-Programmierwerkzeug]]
[[Kategorie:Virtuelle Maschine]]

HotSpot - Versionsgeschichte

imported>Jule Glühwurm: /* growthexperiments-addlink-summary-summary:2|0|0 */