Java Virtual Machine

Die Java Virtual Machine (abgekürzt Java VM oder JVM) ist eine Laufzeitumgebung und virtuelle Maschine für Software. Die Java Virtual Machine führt den so genannten Java-Bytecode aus.

Bytecode entsteht hahahahhah durch Compilierung von Programmen, die in aller Regel in der Programmiersprache Java verfasst wurden. Es ist aber sowohl theoretisch wie praktisch möglich, diesen Bytecode auch aus anderen Programmiersprachen heraus oder direkt mit geeigneten Assemblern zu erzeugen. Umgekehrt ist es mit speziellen Compilern auch möglich, beim Kompilieren statt Bytecode direkt ausführbare Programme für die jeweilige Architektur zu erzeugen.

Der Sinn der Java Virtual Machine und des Bytecodes ist es, plattformunabhängige Programme zu ermöglichen. Die JVM dient dabei als Schnittstelle zur Maschine und zum Betriebssystem. Nachteilig dabei ist, dass zur Ausführung des Bytecodes die JVM benötigt wird, die aber für die meisten Plattformen verfügbar ist, und dass Programme, die in dieser Form vorliegen, oft langsamer ausgeführt werden und mehr Speicher verbrauchen als nativ für die Plattform kompilierte Programme.

Die VM schottet die in ihr laufenden Prozesse (Threads) vom Betriebssystem ab. Dies hat zur Folge, dass es nicht mehr möglich ist, mit systemeigenen Mitteln Prozesse zu kontrollieren. Sie stellt aber auch keine eigenen Funktionen zur Prozesskontrolle und -steuerung bereit. Somit können diese auch nicht von außen beendet werden, wenn sie auf Grund eines Fehlers das Gesamtsystem stören. Dazu muss dann die gesamte VM beendet werden. Manche Java Virtual Machines erlauben allerdings das direkte Mappen von dedizierten Java-Threads auf Betriebssystem-Prozesse.

Der große Vorteil einer Virtual Machine ist aber neben der Plattformunabhängigkeit der Gewinn an Sicherheit. Ein VM überwacht zur Laufzeit die Ausführung des Programms, verhindert also z. B. dass ein Programm in fremde Speicherbereiche oder über Arraygrenzen hinweg liest oder schreibt. Im speziellen Fall von Java fällt diese Überwachung sehr einfach aus, da prinzipiell gar keine Zeiger unterstützt werden, die hierfür leicht verwendet werden könnten. Somit werden die gefürchteten Pufferüberläufe verhindert, die vor allem bei den in C oder C++ geschriebenen Programmen vorkommen und von Angreifern dazu benutzt werden können, fremden Code auf einem System auszuführen, es somit anzugreifen und unter Kontrolle zu bringen.

Aus Performancegründen setzen die meisten Java VMs so genannte JIT-Compiler (JITC) ein, die unmittelbar beim Laufen des Programms den Bytecode "Just In Time" in Maschinencode übersetzen. Eine Weiterentwicklung dieses Ansatzes ist der von Sun entwickelte Hotspot Optimizer. Diese Entwicklung behebt weitgehend den Geschwindigkeitsnachteil der JVM, der hohe Speicherverbrauch bleibt jedoch bestehen. Außerdem gibt es designbedingt einige Einbußen, vor allen Dingen durch die Garbage-Collection. Jedoch gibt es von anderen Herstellern JVMs, die diese Nachteile ebenfalls weitestgehend kompensieren, durch den Einsatz sehr ausgefeilter Techniken (IBM J9 oder Insignia Jeode).

Java-Maschinen stehen für alle gängigen Betriebssysteme zur Verfügung (z. B. Linux, Mac, Palm-OS, Solaris, Windows, usw.).

Die Java VM von Sun ist Teil der JRE (Java-Runtime-Environment / Java-Laufzeitumgebung), die auch sämtliche benötigten Java-Klassenbibliotheken enthält - ein wichtiger Unterschied zu anderen VM-Umgebungen. Die Java Virtual Machine lässt sich durch Erweiterungen wie OSGi weiterhin zu einem dynamischen Framework erweitern, das flexibel Java-Klassen nachladen sowie unterschiedliche Versionen und Abhängigkeiten verwalten kann.

dynamische Optimierung

Das Konzept der Java Virtual Machine hat - zumindest vom theoretischen Standpunkt aus - auch Vorteile. Beispielsweise ist es so, dass zum Zeitpunkt des Compilierens üblicher Software für eine System-Architektur nicht bekannt ist, welche konkrete Eingabe die Software haben wird. Demzufolge muss die Software mit allen Arten von Eingaben zurecht kommen. Die Eingabe wird demnach in Variablen gespeichert. Nach dem Start des Programms werden jedoch viele Variablen nicht mehr geändert. Folglich sind diese - von einem Zeitpunkt kurz nach dem Start an - Konstanten. Wird nun erst nach diesem Zeitpunkt die Software für die System-Architektur compiliert (dies ist bei Java Hotspot der Fall), so können diese Konstanten berücksichtigt werden. Bestimmte Verzweigungen im Programmcode, die nur von solchen "Halbkonstanten" abhängig sind, sind dann für immer eindeutig und stellen somit kein Risiko für eine falsche Branch Prediction dar. Ein solcher Programmcode kann also theoretisch schneller ablaufen als zu früh compilierter Code.

Weblinks

• Liste der Programmiersprachen, welche in Java Bytecode kompilieren.
• Spezifikation der Java VM (englisch)
• Kaffe - freie Java VM