Java 7: Evolution für Java – Revolution für die JVM

Hartmut Schlosser

Java 7 hat zum ersten Mal in der Geschichte von Java neuen Bytecode mit an Bord: Mit der neuen Anweisung invokedynamic lassen sich Methoden aufrufen ohne vorherige Prüfung, zu welcher Klasse die Methode gehört, von welchem Typ ihr Rückgabewert ist oder welche Methodenparameter sie verwendet.

Interessant ist dieses Feature nicht für eine statische Sprache wie Java, bei der der Typ jedes Objekts sowie die gesamte Signatur einer Methode zur Übersetzungszeit feststehen. Dementsprechend kommt inkovedynamic im Java-Compiler nicht zum Einsatz.

Methoden dynamischer Sprachen hingegen verfügen zur Übersetzungszeit über keine festgelegte Signatur, was ihre Implemetierung für die Java Virtual Machine bisher erschwerte.

Aus der Sicht eines JVM-Sprachenimplementierers muss die invokedynamic-Konstruktion also als das wichtigste Feature in Java 7 erscheinen: Und so ist Java 7 auch für JRuby-Mastermind Charles Oliver Nutter mehr als ein rein kosmetisches Release: Dinge wie Project Coin schätzt Nutter als „bescheidene inkrementelle Veränderung“ ein, die Neuerungen auf dem JVM- und JDK-Level nennt Nutter hingegen eine „echte Revolution“.

Java 7 Revolution

invokedynamic könne als eine Möglichkeit gesehen werden, wie JVM-User direkt mit dem Optimierungsbackend der Java Virtual Machine in Kontakt treten können, schreibt Nuttter in seinem Blogeintrag „JRuby and Java 7: What to Expect. Die Logik auch komplizierter Methoden-Aufrufe könne durchschaut und wie bei statischen Aufrufen optimiert werden.

You can look at invokedynamic as a way for JVM users to communicate directly with the optimizing backend of the JVM. Method handles act as both function pointers and as function combinators, allowing a built-in way to construct a call protocol flow from a caller to a callee. You can move arguments around, insert new arguments, process existing arguments and return values, catch exceptions, and perform fast guarded branches between two (or more) paths. Charles Nutter

The invokedynamic bytecode itself provides a bytecode-level hook to which you attach your method handle chain, with the assumption that the JVM can optimize that chain directly into the invokedynamic caller. Charles Nutter

Nutter beschreibt, dass JRuby bereits starken Gebrauch von invokedynamic macht und dabei Performanz-Gewinne von bis zu 150-200 Prozent erzielt wurden. Dabei seien die Arbeiten noch nicht abgeschlossen – die Optimierungen gehen weiter und Nutter bittet die Community, ihre Erfahrungen bzgl. guter – und besonders auch schlechter – Performanz mitzuteilen.

Und sonst?

Bei den anderen Neuerungen in Java 7 sieht Nutter großen Nutzen in den neuen IO APIs (NIO.2). Für JRuby bedeuten diese, dass plattformübergreifend mehr Dateisystem-Operationen unterstützt werden können, ohne auf nativen Code zurückgreifen zu müssen. JRuby-Anwender können Dateisystem-Ereignisse und asynchrone IO-Operationen ohne die Verwendung plattform-spezifischer Bibliotheken ausführen. Bislang wird NIO.2 allerdings noch nicht von den JRuby-Kernklassen unterstützt – was sich laut Nutter aber bald ändern soll.

Generell bringe das neue OpenJDK 7 Performanz-Gewinne im Vergleich zu OpenJDK 6 mit sich, schreibt Nutter. Außerdem habe sich Java 7 in der zurückliegenden einjährigen Testphase als stabil und konsistent erwiesen. Es mussten keine gravierenden Java7-spezifischen Fixes in JRuby durchgeführt werden.

JRuby 1.7 soll aber dennoch nicht vor einem Update-Release des OpenJDK7 erscheinen. Man wolle den Hotspot-Entwicklern genügend Zeit geben, den invokedynamic-Mechanismus weiter zu verbessern, um näher an eine „echte“ invokedynamic-Performance zu kommen.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.