Sun Hotspot 2.0

Die HotSpot VM ist eine komplette Neuentwicklung einer JVM, ohne auf eine vorhandene Java-Maschinen aufzusetzen. Das Design ist eine konsequente Fortentwicklung der Self- und Animorphic Smalltalk Maschinen^A1.

Zur Garbage Collection wird ein exakter generationaler Algorithmus mit zwei Generationen verwendet.

• Die junge Generation hat eine variable Größe von bis zu 2,5 MB und ist in ``Eden'' (80%) und ``Survivor-Space'' (20%) unterteilt. Zur ihrer Bereinigung wird ``Copying Collection'' verwendet.
• Die alte Generation wird mit dem inkrementellen ``Train''-Algorithmus bereinigt. Bevor der Heap vergrößert wird, wird eine vollständige ``Mark-Compact'' Garbage Collection mit Hilfe einer ``Break-Table'' ausgeführt.
• Es existiert ein zusätzlicher Bereich, der sogenannte ``Permanent Object Space'', in dem Klassen und Methoden abgelegt werden. Dieser Bereich wird nur bei einer komplette Garbage Collection bereinigt.

Um Zeiger zwischen Generationen zu protokollieren, wird ``Card Marking'' mit einer Kartengröße von 512 Bytes verwendet. Zur thread-sicheren Allokation wird die globale Freispeichergrenze durch atomares ``Compare-And-Swap'' inkrementiert. Es finden keine thread-lokalen Allokationsbuffer Verwendung.

Die Thread-Implementierung der HotSpot-Maschine stützt sich auf die Betriebssystem-Threads der jeweiligen Platform; die Monitore sind hingegen in der Maschine selbst implementiert. Zum schnelleren rekursiven Erwerb und zur schnelleren Allokation werden Monitore zunächst auf dem Stack angelegt - erst bei Erwerbungskonflikten werden sie auf den Heap befördert.

Der Bytecode wird durch einen in Assembler geschriebene Interpreter und durch einen optimierenden Compiler ausgeführt. Dabei wird der Interpreter erst beim Starten der VM durch einen Makro-Assembler generiert. Dies erlaubt eine optimale Anpassung an die Platform (CPU-Version, OS-Version) und das inlining bestimmter Speicheradressen, die im Verlauf der Sitzung konstant sind (z.B. die Obergrenze des Allokationsbereiches ``Eden''). Die Entscheidung, ob und wann eine Methode übersetzt wird, wird dynamisch durch Profilinformationen entschieden.

Der Compiler trifft teilweise optimistische Annahmen, die durch späteres dynamisches Laden von Klassendefinitionen ungültig werden. Aus diesem Grunde unterstützt die Maschine das De-Optimieren laufender Aktivierungen optimierter Methoden.

Hotspot wird in zwei Ausführungen ausgeliefert:

1.

In einer Client-Version, die für die Ausführung von kurzlebigeren, interaktiven GUI-Applikationen eingesetzt werden soll.

2.

In einer Server-Version, die für den Einsatz von langlebigen Serverapplikationen optimiert wurde.

Der Unterschied zwischen den beiden Versionen findet sich hauptsächlich im eingesetzten Compiler. Der Compiler der Client-Version ist auf einen interaktiven Einsatzt optimiert, d.h., daß die Übersetztgszeit möglichst kurz gehalten wird - auf der anderen Seite ist der erzeugte Code in der Ausführung ineffizienter als der des Server-Compilers.

Der optimierende Compiler der HotSpot Server VM arbeitet mit klassischen Compileralgorithmen, u.a. Register-Allokation durch graph coloring[Chaitin, 1982], CSE durch global value numbering sowie inline caches -- der Einsatz von polymorphic inline caches hat sich jedoch nicht bewährt[Bracha, 1999], daher werden polymorphe Aufrufstellen durch vtables implementiert.