© ecco/Shutterstock.com
Eine Einführung in GraalVM, Oracles neue Virtual Machine

Eine, um alles zu beherrschen


Die HotSpot Java VM ist nun gut zwei Jahrzehnte alt. Seitdem hat sich die Welt der Softwareentwicklung stark verändert. Zeit also, HotSpot in Rente zu schicken? Seit Längerem arbeiten die Oracle Labs an einem neuen Compiler für die JVM, der polyglott und hochperformant sein soll.

Seit einigen Monaten stellt Oracle der Allgemeinheit die ersten Release Candidates der GraalVM, einer neuen virtuellen Maschine, zur Verfügung (zum Zeitpunkt der Niederschrift des Artikels ist RC10 aktuell). Wenn eine Software mit ihrem Namen Bezug auf den heiligen Gral nimmt, legt das die Messlatte gleich um einige Zentimeter höher. Erinnern wir uns: Der heilige Gral verspricht seinem Besitzer nicht weniger als Lebenskraft, Jugend, Nahrung in Hülle und Fülle sowie Glückseligkeit und damit alles in allem quasi die Unsterblichkeit. Entsprechend lang ist auch die Featureliste der GraalVM, die aus einer Reihe von Forschungsprojekten am Institut für Softwaresysteme der Linzer Johannes-Kepler-Universität in enger Zusammenarbeit mit den Oracle Labs hervorgegangen ist.

Nicht ohne Grund ist im Namen nur die Abkürzung VM enthalten und nicht JVM, denn auf einer anderen Architektur kann sie nicht nur Java-Bytecode ausführen, sondern ist eine echte polyglotte virtuelle Maschine, auf der prinzipiell jede Programmiersprache ausgeführt werden kann. Damit stellt die GraalVM etwas Neues dar. Denn auch wenn schon seit Langem der Begriff polyglott für die JVM in Bezug auf Sprachen wie Groovy, Kotlin oder auch JRuby verwendet wird, ist die JVM selbst nicht polyglott: Sie selbst kann nur Bytecode ausführen. Dass es Compiler gibt, die für eine bestimmte Sprache Bytecode für die JVM erzeugen können, hat nichts mit der JVM zu tun, sondern erlaubt es uns Entwicklern nur, mit anderen Sprachen für die JVM entwickeln zu können. Die GraalVM hingegen lässt solche Grenzen hinter sich und ist als universelle Virtual Machine ausgelegt. So unterstützt sie alle Sprachen, für die es einen Bytecode-erzeugenden Compiler gibt, sprich, wer mit Java, Scala, Clojure und Co. arbeitet, kann jetzt schon die GraalVM nutzen. Derzeit unterstützt sie Java bis Version 8; Java 11 und höher sollen später folgen. Neben diesen Sprachen für die JVM können auch Programme in der Statistiksprache R, Python, Ruby, JavaScript sowie LLVM-Bitcode durch die GraalVM ausgeführt werden.

Aber warum braucht es überhaupt eine neue virtuelle Maschine, wenn es doch schon andere gibt? Sicherlich gibt es nicht den einen Grund, und – wie bei einigen Projekten – auch nicht den großen Plan am Anfang. Wohl eher flossen Möglichkeiten und Bedürfnisse zum richtigen Zeitpunkt zusammen. In den vergangenen Jahren sind viele neue Sprachen auf der Bühne der Softwareentwicklung erschienen. Dabei geht es nicht um exotische Sprachen oder Projekte ohne praktische Relevanz für die tägliche Arbeit. Vielmehr geht es um Sprachen wie Scala oder Kotlin, die anderen Paradigmen folgen, oder Sprachen wie Go und Rust, die von Organisationen vorrangig für ihre eigenen Bedürfnisse entwickelt wurden. Die Motivation für viele JVM-basierte Sprachen war es, hinsichtlich der Sprachfeatures in einigen Bereichen besser als Java zu sein und Dinge zu vereinfachen. In anderen Bereichen stellte Java bis jetzt nie eine echte Alternative dar. Sei es, weil die Installation des Java Runtime Environments (JRE) zusammen mit der Anwendung oft zu aufwendig, sei es weil die Start-up-Zeit der Java Virtual Machine vor dem jeweiligen Anwendungshintergrund nicht praktikabel ist. Aber auch Trends in der Softwarearchitektur, wie zum Beispiel Serverless Computing oder schnell skalierende Cloudarchitekturen, bei denen es nicht auf maximalen Durchsatz, sondern auf schnelle Startzeiten ankommt, setzen Java unter Druck. Projekte wie Kotlin/Native bestätigen das ebenso wie der Erfolg von Go in der Systementwicklung.

Die Entwicklung von Java war bis Java 9 eher behäbig als schnell, und der Innovationsdruck ist, wie gerade gezeigt wurde, hoch. Java als weitverbreitete Sprache weiterzuentwickeln ist nicht einfach, denn Änderungen an der Sprache können auch Änderungen an anderen Stellen des JDKs, beispielsweise der JVM, erforderlich machen. Dabei hat HotSpot ein Problem: HotSpot ist in C++ geschrieben, ist komplex und hat eine inzwischen sehr alte Codebasis. Zwar hat sich auch C++ weiterentwickelt, doch eine bestehende Codebasis zu modernisieren, ist aufwendig. Zudem wird C++ immer weniger an den Universitäten gelehrt. Damit ist es schwieriger, auch Nachwuchs für die Arbeit an HotSpot zu finden.

Bezug und Installation

Oracle stellt zwei Varianten der GraalVM bereit: die kostenfrei einsetzbare Community Edition und die kostenpflichtige Enterprise Edition. Beide Varianten sind derzeit nur für macOS und Linux verfügbar. Erwartungsgemäß sind bestimmte Features der Enterprise Edition vorbehalten. So kann von mit der Enterprise Edition erzeugten Native Binarys ein Heapdump gezogen und auf DWARF-Debugging-Informationen zugegriffen werden. Zudem kann die Enterprise Edition bessere Optimierungen vornehmen als die Community Edition. Die Community Edition ist über die Projektwebseite erhältlich, die Enterprise Edition über das Oracle Technology Network. Beide Editionen können als .tar.gz-Datei heruntergeladen werden. Zur Installation ist es daher ausreichend, das jeweilige Archiv zu entpacken und die Variable JAVA_HOME auf das entpackte Verzeichnis zu setzen.

Rückblick

Mit Java 1.3 hielt im April 1999 die HotSpot JVM Einzug in die damals noch sehr junge Java-Welt. Java 1.0 war drei Jahre zuvor erschienen, kannte damals weder innere Klassen noch Reflection. Das Collections Framework kam erst in Java 1.2 hinzu. Diese Version war auch die erste Version mit einem Just-in-Time-Compiler (JIT) für Bytecode, der vorher nur interpretiert ausgeführt wurde. Das liegt jetzt gut zwanzig Jahre zurück und wahrscheinlich ist der eine oder andere Leser zu dieser Zeit noch gar nicht auf der Welt gewesen. Vorherrschend für die Anwendungsentwicklung waren zu dieser Zeit C und C++. Viele Geschäftsanwendungen wurden auch mit Borlands Delphi entwickelt, und das Internet wurde langsam von einer breiteren Gruppe wahrgenommen.

Die meisten Java-Programmierer der ersten Stunde waren der Dominanz von C und C++ entsprechend vorher C/C++-Programmierer, denen der Umstieg auf Java wegen der großen Ähnlichkeit der Sprachen leichtfiel. Aufgrund ihrer Verbreitung und der hohen Geschwindigkeit von C und C++ wurde auch die HotSpot JVM in C++ mit Assemblerteilen geschrieben. Der damals geschriebene Java-Code unterschied sich auch von Code, wie er heute geschrieben würde. Wo heute Streams zum Einsatz kämen, herrschten damals for-Schleifen, und wenn es performancekritisch wurde, galt es, die Erzeugu...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang