|
Java Virtual Machine Die Java Virtual Machine (abgekürzt Java VM oder JVM) ist der Teil der Java-Laufzeitumgebung (Java Runtime Environment, JRE) für Java-Programme, der für die Ausführung des Java-Bytecodes verantwortlich ist. Hierbei wird im Normalfall jedes gestartete Java-Programm in seiner eigenen virtuellen Maschine (VM) ausgeführt. Der andere Teil der Java-Laufzeitumgebung sind die Java-Klassenbibliotheken. Die JVM dient dabei als Schnittstelle zur Maschine und zum Betriebssystem und ist für die meisten Plattformen verfügbar (z. B. Linux, macOS, Palm OS, Solaris, Windows, z/OS). Die JVM ist meist in den Programmiersprachen C oder C++ geschrieben. Die Bestandteile der JVM sind
FunktionsprinzipVom Java-Compiler erzeugter (plattformunabhängiger) Bytecode wird von einer plattformabhängigen Java Virtual Machine ausgeführt. Die erzeugten Bytecode-Dateien (Dateiendung „.class“) werden während der Laufzeit in die lokale Maschinensprache übersetzt. Die virtuelle Maschine arbeitet dabei wie ein Interpreter, ist jedoch wesentlich schneller, da z. B. keine Syntaxüberprüfungen mehr vorgenommen werden müssen. SicherheitsvorteileDie Java Virtual Machine bietet neben der Plattformunabhängigkeit des Bytecodes auch einen Gewinn an Sicherheit. Sie überwacht zur Laufzeit die Ausführung des Programms, verhindert also zum Beispiel Pufferüberläufe, welche zu unvorhersehbarem Verhalten wie etwa dem Absturz des Programmes führen. Im speziellen Fall von Java fällt diese Überwachung sehr einfach aus, da Java nicht direkt Zeiger unterstützt (nur implizit). OptimierungsverfahrenUm die Ausführungsgeschwindigkeit (englisch performance) von Java-Programmen zu erhöhen, setzen die meisten Java-VMs sogenannte JIT-Compiler (JITC) ein, die unmittelbar während des Programmablaufs den Bytecode „Just In Time“ („Gerade rechtzeitig“, oder „Gerade zur rechten Zeit“) dauerhaft in Maschinencode übersetzen. Eine Weiterentwicklung dieses Ansatzes ist der Hotspot-Optimizer von Sun, welcher mit dynamischer Optimierung arbeitet. Dynamische OptimierungOft ist zum Zeitpunkt der Kompilierung nicht bekannt, welche konkrete Eingabe eine Software verarbeiten muss. Demzufolge muss die Software mit allen Arten von Eingaben zurechtkommen. 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 kompiliert (dies ist bei HotSpot der Fall), so können diese Konstanten berücksichtigt werden. Bestimmte Verzweigungen, die nur von solchen „Halbkonstanten“ abhängig sind, sind dann für immer eindeutig und stellen somit kein Risiko für eine falsche Sprungvorhersage dar. Ein solcher Programmcode kann also schneller ablaufen als zu einem früheren Zeitpunkt kompilierter Code. Implementierungen in HardwareAusführungen in Hardware sind Java-Prozessoren, Mikroprozessoren, die Java-Bytecode als Maschinensprache verwenden. Sie konnten sich gegen die schnelle Steigerung der Leistungsfähigkeit von Standard-PC und JVM nicht durchsetzen. Abschottung der ThreadsDie Java VM schottet die in ihr laufenden Prozesse vom Betriebssystem ab (Green Threads). Sie bildet standardmäßig Java-Threads durch Threads des Betriebssystems ab. Nur in Ausnahmefällen erfolgt das Thread-Management durch die Java VM. Somit ist es auch möglich, auf einem Betriebssystem, das kein Multithreading unterstützt, eine Java VM mit vollem Funktionsumfang anzubieten. Die Java VM hat stets volle und standardkonforme Hoheit über die Java-Threads, d. h. der Programmierer braucht nicht die betriebssystemspezifischen Multi-Threading/Tasking/Processing-Eigenschaften zu berücksichtigen und kann sich stets auf die JRE verlassen. Nachteil ist, dass Probleme, die von einem Thread ausgehen, seitens des Betriebssystems dem gesamten Prozess zugeordnet werden. Gängige Betriebssysteme (wie zum Beispiel Linux, Windows) erlauben Kontrolle über diese „nativen“ Threads allenfalls über Software von Drittanbietern, wie beispielsweise die mit dem JDK mitgelieferte VisualVM. Standardwerkzeuge wie beispielsweise der Windows Taskmanager zeigen Systemthreads jedoch nicht an. JVM-SprachenNeben Java gibt es auch andere Sprachen, die als Programmiersprachen für JVM-Programme benutzt werden können. Unter anderem folgende Sprachen können auf einer JVM laufen:
Daneben gibt es eine Reihe von Skripting-Sprachen, die von Java aus aufrufbar sind. Dazu gehört JavaScript (mittlerweile standardisiert als ECMAScript) mit dem „Rhino“-Interpreter (ein Mozilla-Projekt) bis Version 7 bzw. mit dem „Nashorn“-Interpreter ab Version 8. Auch JavaFX enthielt in den Versionen 1.x eine Skripting-Sprache vor allem für grafische Elemente, ist aber ab Version 2.0 in pure Java implementiert. Kompilierung in JavaScriptMit der kontinuierlichen Verbesserung der JavaScript-Ausführungsgeschwindigkeit, kombiniert mit der verstärkten Nutzung mobiler Geräte, deren Webbrowser keine Unterstützung für Plugins bereitstellen, gibt es Bemühungen, diese Benutzer durch Kompilierung in JavaScript anzusprechen. Es ist möglich, den Quellcode oder JVM-Bytecode nach JavaScript zu kompilieren. Die Kompilierung des JVM-Bytecodes, der für alle JVM-Sprachen universell ist, ermöglicht es, auf dem bestehenden Compiler der Sprache aufzubauen und Bytecode zu erstellen. Die wichtigsten JVM-Bytecodes für JavaScript-Compiler sind TeaVM[5], der Compiler im Dragome Web SDK[6], Bck2Brwsr[7], und j2js-Compiler[8]. Zu den führenden Compilern von JVM-Sprachen zu JavaScript gehören der Java-zu-JavaScript-Compiler in Google Web Toolkit, Clojurescript (Clojure), GrooScript (Apache Groovy), Scala.js (Scala) und andere[9]. Siehe auch
WeblinksCommons: Java Virtual Machine – Sammlung von Bildern, Videos und Audiodateien
Einzelnachweise
|
