Java 9 bekommt Ahead-of-Time-Compiler

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.