Java 9 bekommt Ahead-of-Time-Compiler

(c) Shutterstock/Alexandra Lande
Was im September 2016 im JEP 295 vorgeschlagen wurde, ist nun offiziell dem Java-9-Release zugewiesen: Ahead-of-Time-Kompilierung wird Einzug in die Java-VM halten.
Bisher unterstützte die HotSpot JVM lediglich Just-in-Time-Kompilierung (JIT). Prinzipiell wird dabei der Bytecode eines Java-Programmes nicht vor dem Programmstart, sondern erst zur Laufzeit in ausführbaren Maschinencode übersetzt. Dank zahlreicher Optimierungen läuft dies mittlerweile überaus rasant ab – doch manchem nicht rasant genug.
Mit dem Ziel, die Startzeiten von Java-Programmen zu verbessern, hatte der Leiter des HotSpot-Compiler-Teams Mikael Vidstedt deshalb im September das Java Enhancement Proposal (JEP) 295: „Ahead-of-Time Compilation“ vorgeschlagen, das nun offiziell für Java 9 angenommen wurde.
Die Motivation für den JEP liest sich dort wie folgt:
JIT compilers are fast, but Java programs can become so large that it takes a long time for the JIT to warm up completely. Infrequently-used Java methods might never be compiled at all, potentially incurring a performance penalty due to repeated interpreted invocations.
javac’s neuer Bruder: jaotc
Die AOT-Kompilierung soll durch ein neues Tool namens jaotc durchgeführt werden, das neben dem javac-Compilier in der Java-Installation enthalten sein wird. Als Code-Generierungs-Backend kommt das Projekt Graal zum Einsatz, in dessen Rahmen VM-Funktionalität über Java APIs zugänglich gemacht wird.
Um beispielsweise das AOT-kompilierte java.base
-Modul zu nutzen, muss das Modul kompiliert werden und die resultierende AOT Library in das JDK-Installationsverzeichnis kopiert oder auf der Java Kommandozeil spezifiziert werden. Zur Ausführung der AOT-Kompilierung kommt es durch folgende Anweisung:
jaotc --output libHelloWorld.so HelloWorld.class
Danach muss noch die generierte AOT Library angegeben werden:
java -XX:AOTLibrary=./libHelloWorld.so HelloWorld
Einschränkungen
Nun sind für das erste Release der AOT-Kompilierung einige Einschränkungen zu beachten. Zunächst einmal wird java.base
das einzige unterstützte Modul sein. Grund dafür ist, dass der Java-Code in diesem Modul seht gut bekannt ist und sich deshalb für die Einführung einer derart wichtigen Neuerung eignet. AOT-Kompilierung von anderen JDK-Modulen oder gar von User-Code wird lediglich als „experimentelles Feature“ – also quasi auf eigene Gefahr – möglich sein.
Lesen Sie auch: Java 9 Release-Datum steht fest: Oracle legt neue Roadmap vor
Zudem wird das initiale Release des AOT-Compilers lediglich 64-bit Linux-Systeme mit 64-bit Java unterstützen. Auch werden dynamisch generierte Klassen und Bytecode, wie insbesondere von Lambda-Ausdrücken und dem Invoke-Dynamic-Feature eingesetzt, nicht zuverlässig kompiliert. Als Garbage Collector werden G1 und Parallel GC unterstützt.
Die komplette Liste der Einschränkungen:
- AOT initial release in JDK 9 is only supported on 64-bit Linux systems running 64-bit Java.
- The system should have installed libelf to allow generation of AOT shared libraries (.so) as result of AOT compilation.
- AOT compilation should be executed on the same system or a system with the same configuration on which AOT code will be used by Java application.
- For the initial release in JDK 9 the only supported module for AOT compilation will be java.base.
- Only G1 and Parallel GC are supported now.
- May not compile java code which uses dynamically generated classes and bytecode (lambda expressions, invoke dynamic).
- The same Java run-time configuration should be used during AOT compilation and execution. For example, the jaotc tool should be run with Parallel GC (using the -J flag) if an application will also use Parallel GC with AOT code.
Diese Begrenzungen könnten in einem zukünftigen Release zumindest teilweise aufgehoben werden, doch Genaueres zu Oracles AOT-Plänen ist noch nicht bekannt. Das JEP-Proposal enthält lediglich den lapidaren Satz: „These limitations may be addressed in future releases.“
Lesen Sie auch: Neuer Garbage Collector in Java 9: Was ändert sich – was bleibt?
Ob eine Anwendung tatsächlich von vorkompiliertem Code profitiert, dürfte stark vom Einzelfall abhängen. Performance-Tests hätten hier ein gemischtes Bild ergeben, heißt es im Proposal. Mögliche Performance-Einbußen lassen sich aber durch das Abschalten der AOT-Kompilierung vermeiden:
Since the AOT feature is an opt-in feature, possible performance regressions with user applications are avoidable. If a user finds that an application starts up more slowly, or doesn’t reach the expected peak performance, they can just switch AOT off with the -XX:-UseAOT flag, or remove any AOT libraries.
Eine genaue Beschreibung über Motivation und Funktionsweise der AOT-Kompilierung ist dem offiziellen JEP 295 zu entnehmen.
Hinterlasse einen Kommentar