JEP 544 bringt vorab kompilierten Maschinencode in den AOT-Cache von JDK 28
Victoria Shinder1 Min. LesezeitJEP 544, Ahead-of-Time Code Compilation, gehört zu JDK 28. Die JEP-Seite führt ihn als in Release 28 integriert, verantwortlich ist John Rose; als Ziel für JDK 28 wurde er am 25. Oktober auf Inside Java angekündigt. Die Funktion erweitert den bestehenden AOT-Cache aus Project Leyden: In einem Trainingslauf kompiliert HotSpot Anwendungscode zu optimiertem Maschinencode und legt ihn im Cache ab; spätere Produktionsläufe laden diesen Code beim Start, statt auf das Aufwärmen von Interpreter, C1 und C2 zu warten.
Die Ziele sind eng und praktisch. Anwendungen sollen schneller Spitzenleistung erreichen und sie halten, wenn sich die Last ändert; Änderungen an Anwendungs-, Bibliotheks- oder Framework-Code sind nicht nötig, und an der HotSpot-Konfiguration ändert sich nichts außer der Anforderung des AOT-Caches. Unterstützt bleiben die Collectoren Serial, Parallel, G1, Shenandoah und ZGC; genutzt wird der vorhandene Ablauf zur Cache-Erstellung statt eines neuen, und der Übergang von AOT- zu JIT-kompiliertem Code bleibt für die Anwendung unsichtbar.
Ebenso aufschlussreich sind die Nicht-Ziele. Einen reinen AOT-Modus gibt es nicht: Ein Lauf mischt beide Codearten und wechselt nach Bedarf. Cross-Kompilierung gibt es nicht — Code aus dem Trainingslauf muss auf derselben CPU-Architektur mit denselben Merkmalen laufen. Vorerst werden nur x64 und AArch64 unterstützt. Der JEP baut auf JEP 483 (AOT-Klassenladen und -Linken) und JEP 515 (AOT-Methodenprofile) auf.
Was das bedeutet
Das ist der Schritt nach den Profilen: JDK 25 ließ den Cache Profile mitführen, damit der JIT klüger startet, JDK 28 lässt ihn das kompilierte Ergebnis mitführen. Der Haken für den Betrieb ist die Bindung an dieselbe CPU — ein auf einem Instanztyp trainierter Cache ist auf einem anderen nicht verwendbar, also gehört der Trainingslauf in dieselbe Pipeline, die die Hardware auswählt.