Jens Schwarz
Tübingen, den 3. August 1998
Die Entwicklung von Java wurde von Sun-Microsystems 1991 im Rahmen eines Forschungsprojektes zur Entwicklung von Software für eingebettete Systeme in Konsumelektronikgeräten, wie z.B. Fernseher, Videorecorder, Toaster und anderen Haushaltsgeräte, begonnen. Deshalb sollte die Sprache klein, schnell, sicher und leicht portierbar sein. Das gleiche Ziel macht Java zu einer idealen Sprache zur Verbreitung ausführbarer Programme über das World-Wide-Web. Das gesamte Java-Konzept läßt sich in drei Teile gliedern. Es besteht nach Dalheimer [Da] aus:
Bei der Entwicklung des Java-Konzepts wurde Wert darauf gelegt, für eine Implementierung der Java Virtual Machine möglichst keine Vorgaben zu machen, um die jeweiligen Möglichkeiten der zu Grunde liegenden Plattform optimal nutzen zu können. Die Java Virtual Machine wird gleichzeitig genau spezifiziert (z.B. die elementaren Datentypen). Dadurch sind Java-Klassen plattformunabhängig und portabel.
Für die Java Virtual Machine sind sieben elementare und zwei interne Datentypen erklärt, deren Größen genau festgelegt sind. So sind z.B. Integer-Werte immer 4 Bytes groß. Es werden vorzeichenbehaftete Ganzzahlen im Zweierkomplement, Fließkommazahlen einfacher oder doppelter Genauigkeit im IEEE 754-Format und Zeichenwerte unter anderem im Unicode-Format benutzt.
Bei herkömmlichen Programmiersprachen wird der Quelltext entweder nach der Erstellung in nativen Maschinencode für bestimmte Prozessoren übersetzt (Compiler) oder zur Laufzeit interpretiert (Interpreter). Java Programme hingegen werden zunächst in eine Maschinensprache für die Java Virtual Machine, den Bytecode, übersetzt. Dieser in einer class-Datei gespeicherte Code kann dann auf jeder Maschine die eine Java Virtual Machine implementiert zum Ablauf gebracht werden (Abbildung 1.1 und 1.2).
Abbildung: Kompilierung herkömmlicher Programme [LP]
Abbildung 1.2: Kompilierung eines Java-Programms [LP]
Die Maschinenbefehle werden dabei durch ein Byte lange Opcodes dargestellt. Die Anzahl und Größe der direkt nachfolgenden Operanden ist vom jeweiligen Opcode abhängig. Im Gegensatz zu manchen realen Prozessoren (mit einem kleinsten Opcode von 16 Bit) verlangt die Java Virtual Machine nicht, daß 16 Bit große Operanden an durch zwei teilbaren Adressen liegen. Auf solchen Rechnerarchitekturen kann dies von Nachteil sein, da aber normalerweise keine Füllbytes notwendig werden, führt dies zu kompakterem Code. Dies ist vor allem deshalb wichtig, da die Netzgeschwindigkeit, z.B. im Internet, fast immer mehr Zeitanteil als die tatsächliche Ausführung des Programms in Anspruch nimmt.
Die Länge von einem Byte ermöglicht 256 Befehle, von denen momentan ungefähr 200 definiert sind. Sie lassen sich wie folgt unterteilen:
Jeder Opcode besitzt eine bestimmte Anzahl von Operanden, die direkt nach ihm im Bytecode gespeichert sind. Die Operanden der Befehle tableswitch und lookupswitch müssen an einer durch vier teilbaren Position im Bytecode liegen. Dies sind die einzigen Fälle in denen Füllbytes notwendig sind.
Da die Java Virtual Machine keine Register zur Speicherung von Operanden und Ergebnissen von Befehlen benutzt, liegen diese auf einem Operandenstack. Z.B. erwartet der für die Addition zuständige Opcode iadd (Abbildung 1.3) zwei Integer-Werte (16-Bit), die er vom Operandenstack nimmt, addiert und deren Summe wieder auf dem Operandenstack ablegt. Der Opcode new (Abbildung 1.3) erwartet zwei Bytes als Operanden, die zu einem Index in den Konstantenpool zusammengesetzt werden. Dort steht ein Klasseneintrag, aus dem die Klasse bestimmt wird, von der ein neues Objekt instanziert und eine Objektreferenz darauf auf den Operandenstapel gelegt wird. In der folgenden Grafik sind zunächst die Formate dieser Befehle im Bytecode, anschließend jeweils das obere Ende des Stacks vor (links) und nach (rechts) der Operation dargestellt.
Abbildung 1.3: Die Befehle iadd und new
{
get_next_opcode();
get_operands();
execute_opcode();
if( !opcode_advanced_pc_register )
advance_pc_register();
} while (opcodes_left());
Der Bytecode einer class-Datei wird einem Java-Interpreter übergeben, der nach der Initialisierung und dem Laden etwa folgende Schleife ausführt:
do
Die Java Virtual Machine verfügt über einen Heap, einen Stack, einen Methodenbereich und verschiedene Register zur internen Verwaltung. In Abbildung 1.4 ist der Zusammenhang der einzelnen Bestandteile dargestellt.
Abbildung 1.4: Die Java Virtual Machine
Der Java-Stapel und der Operandenstapel sind nicht identisch. Jeder Thread der Java Virtual Machine verfügt über einen eigenen Java-Stapel, jeder Rahmen (engl. frame) einer Methode über einen eigenen Operandenstapel [LY].
Der Konstantenpool einer Klasse ist auch im Methodenbereich gespeichert. Die Befehle der Java Virtual Machine arbeiten auf dem Operandenstapel, da keine Datenregister vorhanden sind.
Die auf dem Java-Stapel abgelegten Rahmen speichern die Laufzeitumgebung der einzelnen Methoden. Sie enthalten Informationen, die die Java Virtual Machine während der Laufzeit eines Programms benötigt. Die normalen Funktionen der Rahmen sind: dynamisches Binden, Parameterübergabe, Rücksprünge aus Methoden und das Weiterreichen von Ausnahmezuständen und Fehlern. Die Rahmen enthalten weiter die lokalen Variablen, einen Operandenstapel, die Register der aufrufenden Methode. Je nach reaImplementierung können sie auch Debugging-Informationen und Ähnliches enthalten.
Die Anzahl und Größe der Register eines Prozessors beeinflussen seine Leistungsfähigkeit, da er auf diese ,,internen`` Speichereinheiten besonders schnell zugreifen kann. Obwohl die Java Virtual Machine eine Spezifikation für einen Prozessor ist, besitzt sie keine Register in die Daten zur Ausführung von Operationen geladen werden. Dadurch können Java Programme auch auf Prozessoren mit wenig Registern relativ effizient ablaufen. Die Java Virtual Machine führt ihre Operationen auf dem Operandenstapel aus. Zur internen Verwaltung besitzt sie dennoch vier Register: pc, vars, optop und frame (diese Bezeichnungen müssen nicht verwendet werden, haben sich aber eingebürgert).
Der Java-Stapel ist das wichtigste Element der Java Virtual Machine, da sie keine Datenregister besitzt. Er speichert die Rahmen der einzelnen Methoden, die die Operanden-Stapel enthalten, auf denen gerechnet wird. Der Java-Stapel entspricht nicht dem Stack der realen Maschine, auf der ein Java Programm abläuft, sondern einer eigenen Datenstruktur, die von der Java Virtual Machine verwaltet wird, die je nach Implementierung eine feste Größe besitzen, expandieren oder auch schrumpfen kann. Der Java-Stapel besteht aus 32-Bit breiten Einträgen. 64-Bit Datentypen, wie z.B. long-Werte, benutzen zwei Positionen.
Die Bytecode-Befehle arbeiten auf dem Operandenstapel, den jeder Rahmen enthält.
Auf dem Heap der Java Virtual Machine werden neu erstellte Instanzen (Objekte) abgelegt. Ob die Java Virtual Machine für jedes Objekt vom Betriebsystem des Rechners Speicher anfordert oder einen größeren Speicherbereich selbst als Heap verwaltet, ist nicht spezifiziert. Da die Java Virtual Machine mit einer Freispeicherverwaltung arbeitet, muß der Programmierer den nicht mehr benötigten Speicher nicht wieder freigeben (und kann dies auch nicht). Mit welcher Technik eine Java Virtual Machine die Freispeicherverwaltung durchführt ist nicht festgelegt. Ebensowenig der Zeitpunkt. Jedoch kann mit einem Aufruf der Methode gc() (Garbage Collection) eine Speicherbereinigung erzwungen werden.
Im Methodenbereich werden die Strukturen der Klassen, also der Konstantenpool, die Methodendaten und der Bytecode der Methoden und Konstruktoren gespeichert. Er wird beim Starten der Java Virtual Machine angelegt und von allen Threads gemeinsam genutzt. Weder der Speicherort des Methodenbereichs noch die Verwaltung des Bytecode ist festgelegt. Der Methodenbereich kann eine feste Größe haben, expandieren oder schrumpfen und muß nicht zusammenhängend sein.
Die class-Datei ist eine grundlegende Darstellung des Java-Systems. Für jede Klasse erzeugt der Compiler eine class-Datei. In ihr werden verschiedene Informationen über die Klasse und der Bytecode gespeichert.
Die class-Datei besitzt ein genau definiertes Format, das nachfolgend dargestellt ist:
{
int Erkennungszahl;
short Subversionsnummer;
short Versionsnummer;
short Anzahl_Konstanten;
Konstantenpooleintrag Konstantenpool [Anzahl_Konstanten - 1];
short Merkmale;
short Klasse;
short Superklasse;
short Anzahl_Interfaces;
short Interfaces[Anzahl_Interfaces];
short Anzahl_Felder;
Feldeintrag Felder[Anzahl_Felder];
short Anzahl_Methoden;
Methodeneintrag Methoden[Anzahl_Methoden];
short Anzahl_Attribute;
Attributeintrag Attribute[Anzahl_Attribute];
}
Klassendatei
Die einzelnen Bestandteile können unterschiedliche Länge besitzen, weswegen erst die gesamte class-Datei eingelesen werden muß, bevor auf alle Informationen zugegriffen werden kann. Im folgenden werden nun die wichtigen Elemente der class-Datei beschrieben.
Im Konstantenpool sind sämtliche in einer Java-Klasse vorkommenden Konstanten abgelegt. Es gibt zwölf verschiedene Typen unterschiedlicher Länge, wie z.B. für Unicode (16-Bit Zeichencodierung), Integer, Float, Class oder Methodref. Deshalb kann auf weiter hinten liegende Einträge erst nach Überprüfung der weiter vorn liegenden zurückgegriffen werden. Die Länge der einzelnen Einträge ergibt sich aus ihrem Typ oder ist mit ihnen gespeichert. Jede Klasse kann bis zu 65535 Einträge aufnehmen, die jeweils mit einem ein Byte großen Feld beginnen, das den Typ des Eintrags angibt. Ein Unicode-Eintrag hat beispielsweise folgende Pseudo-C-Struktur:
{
byte Typ;
short Länge;
short Zeichen[Länge];
}
CONSTANT_Unicode_Eintrag
Ein Methodeneintrag hat folgende Pseudo-C-Struktur:
{
short Merkmale;
short Namensindex;
short Signaturindex;
short Anzahl_Attribute;
Attributeintrag Attribute[Anzahl_Attribute];
}
Methodeneintrag
Das Feld Merkmale speichert Merkmale der Methoden, wie public, protected, synchronized usw. Der Namensindex verweist auf eine Utf8-Konstante im Konstantenpool, die den Namen der Methode enthält. Der Signaturindex zeigt auf eine Utf8-Konstante (Codierungsform für Unicode mit unterschiedlicher Anzahl von Bytes je nach Zeichen) im Konstantenpool, die Typen der Parameter und des Rückgabewertes der Methode speichert. Die Attribute der Methodeneinträge sind besonders wichtig, da der Code einer Methode im Code-Attribut und die Ausnahmentabelle im Exceptions-Attribut gespeichert sind.
Attribute beschreiben Klassen, Methoden und Felder näher. Jedes Attribut ist durch seinen Namen, eine Utf8-Konstante, gekennzeichnet. Attribute mit unbekannten Namen müssen beim Lesen übersprungen werden. Dadurch können neue Attribute (z.B. zum Debuggen) hinzugefügt werden, ohne daß ältere Java-Interpreter die class-Datei nicht mehr ausführen können.
Für Klassen existiert momentan nur das Source-File-Attribut, für Felder nur das ConstantValue-Attribut. Methoden kennen zwei wichtige Attribute, das Code-Attribut und das Exceptions-Attribut.
Das Java-System wird durch verschiedene Elemente der Java Virtual Machine zu einem sicheren und leistungsfähigen Programmentwicklungskonzept. Besonders die Freispeicherverwaltung und Teile der Ausnahmebehandlung gehören zu den Unterschieden zu Sprachen wie z.B. C++. Die Mechanismen für das dem Multitasking ähnliche Multithreading sind eine weitere besondere Eigenschaft der Java Virtual Machine.
In Java wird die Freigabe nicht mehr benötigter Objekte von der Freispeicherverwaltung der Java Virtual Machine übernommen. Fehler wie Speicherlecks, doppelte Freigabe ein und desselben Objektes oder Freigabe nie allozierten Speichers können so nicht entstehen. Die einfachere Programmierung und geringere Fehleranfälligkeit wird jedoch mit größerer Laufzeit bezahlt. Die Spezifikation der Java Virtual Machine läßt die Art und Weise, wie die Garbage Collection zu geschehen hat, offen. Auch der Zeitpunkt ist nicht festgelegt. So kann je nach System ein effizientes Verfahren angewandt werden.
Es gibt verschiedene Techniken zur Freispeicherverwaltung. Die zwei bekanntesten sind das reference-counting- und das mark-and-sweep-Verfahren. Beim reference-counting-Verfahren werden für jedes Objekt die dazugehörigen Referenzen gezählt. Verschwindet eine Referenz wieder aus dem Gültigkeitsbereich, wird der Zähler erniedrigt und sobald er wieder 0 erreicht, kann das Objekt gefahrlos gelöscht werden.
Der Java-Interpreter von JavaSoft verwendet das meist geeignetere Mark-and-sweep-Verfahren. Dieses Verfahren geht von einigen immer zugänglichen Objektreferenzen (z.B. globale statische Variablen) aus. Alle dort referenzierten Objekte werden markiert und anschließend rekursiv alle von den neu markierten Objekten referenzierte Objekte. In der folgenden Sweep-Phase werden alle nicht-markierten Objekte gelöscht und die verbleibenden im Speicher verschoben, um einen zusammenhängenden Speicherblock zu belegen. Die Freispeicherverwaltung läuft in einem eigenen Thread und somit im Hintergrund.
Multithreading ist das Ausführen mehrerer Teile eines Programms quasi gleichzeitig. Die einzelnen Teile werden als Threads bezeichnet. Zu den auftretenden Problemen, wie Synchronisation und die Benutzung gleicher Variablen durch verschiedene Threads, sind im Java-System Lösungen, wie z.B. Monitore als Sperrmechanismen, vorhanden. Dennoch können von der Zeit abhängige Ergebnisse auftreten. Das folgende Beispiel zeigt die Problematik:
void hither() {
a=b;
}
void yon() {
b=a;
}
}
Class Sample {
int a=1,b=2;
Laufen die Methoden hither() und yon() der Klasse Sample jeweils in einem eigenen Thread, sind die Werte von a und b nach Ende dieser Threads nicht vorhersehbar.
Ein Thread besitzt entweder die Dämoneneigenschaft oder nicht, was unter anderem für das Ausführungsende eines Java-Programms von Bedeutung ist.
Die Ausnahmebehandlung im Java-System ist der von C++ nachgebildet, hat aber noch einige Verbesserungen erfahren. Es werden try-Blöcke markiert, denen catch-Klauseln folgen, in denen mögliche Ausnahmen und deren Behandlung aufgeführt sind. Es kann an jeder Stelle im Programm eine Ausnahme auftreten, für die es möglicherweise in der catch-Klausel des aktuellen try- Block eine Behandlungsroutine gibt, die auf diese Ausnahme reagiert. Tritt eine nicht aufgeführte Ausnahme in einem try-Block auf, wird die Ausnahme an den nächsthöcheren Block weitergegeben. Wird der äußerste Block erreicht, ohne daß die Ausnahme behandelt wurde, bricht die Programmausführung ab. Zusätzlich bietet Java einen sogenannten finally-Block an, der nach verlassen des try-Blocks auf jeden Fall, ob Ausnahme oder nicht, ausgeführt wird. Die finally-Blöcke sind für Aufräumarbeiten gedacht und runden das Konzept der Ausnahmebehandlung ab.
Eine Java Virtual Machine beginnt die Ausführung mit dem Aufruf der main()-Methode einer angegebenen Klasse, die dadurch geladen, an andere von ihr benutzte Typen gebunden und initialisiert wird [LY]. Liegt der Java Virtual Machine noch keine Binärdarstellung der Klasse vor, wird der Klassenlader aufgerufen. Beim darauffolgenden Binden durchläuft der vorliegende Bytecode zunächst eine Verifikation, bei der er auf richtige Struktur und mögliche Operandenstapelüber- und unterläufe geprüft wird. Die Vorbereitung legt die nötigen Speicherbereiche für die Klasse an und die optionale Auflösung prüft die symbolischen Referenzen zu anderen Klassen und Schnittstellen. Nach erfolgreichem Laden und Binden werden die Initialisierer in textueller Reihenfolge aufgerufen und schließlich die main()-Methode der angegebenen Klasse ausgeführt. Beim Abschluß einer Klasseninstanz wird die eventuell vorhandene finalize-Methode ausgeführt.
Für das Programmende gibt es zwei Möglichkeiten. Entweder alle Threads ohne Dämoneneigenschaft haben ihr Ende erreicht oder ein exit-Aufruf besteht die nötige Sicherheitsprüfung.
Ein Java Programm, das von einem Java-Compiler, wie z.B. javac von Java-Soft, in eine class-Datei übersetzt worden ist, kann auf jedem Rechner, der eine Java Virtual Machine implementiert, ausgeführt werden. Dies kann durch einen Java Interpreter, einen Just-in-Time Compiler oder einen Java Prozessor geschehen (Abbildung 1.6).
Abbildung: Die drei Ausführungsmodelle der JVM
Ein Java Interpreter interpretiert die Befehle des Bytecodes und führt sie aus. Dafür durchläuft er in etwa die 1.2.2 beschriebene Schleife. Bei jeder Ausführung eines Bytecode-Befehls wird dieser aufs Neue in nativen Maschinenbefehle übersetzt, die dann ausgeführt werden.
Ein Just-in-Time Compiler ist der Bestandteil mancher Java Interpreter, der während der Laufzeit des Java-Programms Teile des Bytecodes in nativen Code übersetzt. Dadurch wird ein erheblicher Geschwindigkeitsgewinn erzielt, bei jedoch gleichzeitiger Expansion des Codes.
Java Prozessoren sind ,,echte`` Prozessoren, die der Spezifikation der Java Virtual Machine entsprechen und somit class-Dateien direkt ausführen können.
Java Prozessoren könnten vor allem bei großen Java Applikationen Geschwindigkeitsvorteile bringen. Auch in billigen Netzwerkcomputern und eingebetteten Systemen könnten sie zum Einsatz kommen.
Java Prozessoren, wie picoJava I von Sun Microelectronics, befinden sich noch im Planungsstadium. Aus diesem Grund werden hier nur kurz wesentliche Bestandteile dieses Prozessortyps aufgeführt.
Um einen Prozessor zu entwerfen, der die Java Virtual Machine effektiv implementiert, benutzt Sun Microelectronics eine einfache RISC-ähnliche Architektur [WP].
Abbildung 2.1: Der Aufbau von picoJava I
Der in der Mitte dargestellte Stack-Cache besitzt 64 32-Bit Register und speichert die Spitze des Java-Stack. Auf dem Java-Stack werden Parameter und lokale Variablen, Methodenrahmen und Operanden abgelegt. Bei picoJava I ist ein Überlappen zwischen verschiedenen Methoden möglich, wodurch die Parameterübergabe ohne Kopiervorgang geschehen kann.
Es können mehrere, unterschiedlich große Rahmen im Stack-Cache liegen, aber er kann auch von einem Rahmen ausgefüllt werden.
Abbildung 2.2: Der Stack des picoJava I
Der Stack-Cache wird wie ein kreisförmiger Puffer gemanagt. Der sogenannte ,,Dribbler`` lagert Daten beim Vollaufen des Stack-Cache in den Daten-Cache aus. Der Stack-Cache erhöht die Zugriffszeit auf die Spitze des Stacks.
Durch Pipelining wird ein Befehl in mehrere Teile gegliedert, die alle gleichviel Zeit benötigen. Für picoJava I wird eine einfache RISC-ähnliche Pipeline mit nur vier Stufen (fetch, decode, execute, write-back) benutzt.
Befehle zum Berechnen von Daten (z.B. iadd) arbeiten nur mit Stack-Daten und nie mit Daten aus dem Speicher. Dies erleichtert das Pipelining von Rechen- und Speicherbefehlen.
Abbildung 2.3: Die Pipeline des picoJava I
Sun's Dribbler ist eine clevere Methode, um Daten zwischenzuspeichern und sie auf den Stack zurückzugeben, wenn die Register vollaufen [Wa]. Sind alle 64 Register des Stack-Cache voll und es wird noch mehr Platz benötigt, kommt diese Methode zum Einsatz. Sie läuft im Hintergrund und speichert einen Teil des Stack-Cache im Daten-Cache zwischen, um ihn auf den Stack-Cache zurückzulegen, sobald er benötigt wird.
Abbildung 2.4: Der Dribbler des picoJava I
Momentan befinden sich Java-Prozessoren noch in der Entwicklungsphase und sind noch nicht auf dem Markt. Ob sie einen ähnlichen Erfolg schaffen können, wie Java selbst ist fraglich. Zwar könnten laut Sun auf Java-Prozessoren Bytecode bis zu 12-mal schneller als auf einem Java-Interpreter ablaufen, jedoch müssen sie mit der Entwicklung von immer schneller werdenden Just-in-time-Compilern in Verbindung mit neuen herkömmlichen Prozessoren standhalten. Der Meinung einiger Prozessoranbieter zu Folge sind ihre RISC und CISC Architekturen für Java gut geeignet. Außerdem ist eine Umsetzung der Stapel-basierten Architektur in Hardware schwierig.
