Geschichte der Frage
Die Einführung von invokedynamic in Java 7 über JSR 292 brachte die MethodHandle API zur Unterstützung dynamischer Sprachimplementierungen auf der JVM. Die Herausforderung bestand darin, dass MethodHandle.invoke jede Kombination von Argumenttypen und Rückgabetypen akzeptieren musste, ohne Tausende von Überladungen zu deklarieren. Die JVM-Architekten lösten dies, indem sie das Konzept von polymorphen Methodensignaturen einführten, die intern durch die Annotation @PolymorphicSignature im java.lang.invoke-Paket gekennzeichnet sind.
Das Problem
Die Standard-Java-Methodenaufrufe erfordern, dass der Compiler eine invokevirtual (oder ähnliche) Anweisung ausgibt, die auf einen spezifischen Methodendeskriptor im konstanten Pool verweist, der genau mit der deklarierten Signatur der Methode übereinstimmt. Wenn MethodHandle.invoke so deklariert wäre, dass es Object... args annimmt, müsste jeder Aufrufort Boxing und Array-Zuweisung erfordern, was die Leistungsziele untergräbt. Umgekehrt wäre es unmöglich, Überladungen für jede mögliche Signaturkombination zu deklarieren, was die Class-Datei unendlich aufblähen würde.
Die Lösung
Die JVM behandelt Methoden, die mit @PolymorphicSignature annotiert sind, speziell. Wenn der Compiler mit einem Aufruf einer solchen Methode konfrontiert wird, ignoriert er die deklarierte Signatur und generiert stattdessen eine invokevirtual-Anweisung, deren Methodendeskriptor exakt den ausgelöschten Typen der Argumente und des Rückgabetyps am Aufrufort entspricht. Dadurch kann MethodHandle.invokeExact als akzeptierend (Object)Object im Quellcode erscheinen, aber zu (String)int an einem bestimmten Aufrufort kompiliert werden. Die JVM verbindet diesen Aufruf dann direkt mit dem Einstiegspunkt der Zielmethode ohne Adapter-Overhead.
import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; public class PolymorphicExample { public static void main(String[] args) throws Throwable { MethodHandle handle = MethodHandles.lookup() .findVirtual(String.class, "length", MethodType.methodType(int.class)); // Der Compiler generiert invokevirtual mit Deskriptor (String)int // obwohl invokeExact als (Object)Object im Bytecode deklariert ist int result = (int) handle.invokeExact("hello"); System.out.println(result); // Gibt aus: 5 } }
Problembeschreibung
Beim Aufbau eines Hochdurchsatz-Eventverarbeitungsrahmens für Finanz-Tickdaten mussten wir eingehende Nachrichten an registrierte Handler mit einer Reflexions-ähnlichen Flexibilität weiterleiten, jedoch ohne Zuweisungskosten. Jede Handler-Methode hatte unterschiedliche Signaturen – einige akzeptierten long-Zeitstempel, andere BigDecimal-Preise – was die generische Weiterleitung ohne Boxing von Primitiven herausfordernd machte.
Verschiedene in Betracht gezogene Lösungen
Dynamische Bytecode-Generierung beinhaltete die Verwendung von ASM oder ByteBuddy, um Proxy-Klassen für jede Handler-Signatur zur Registrierungszeit zu generieren. Dieser Ansatz bot nach dem Warm-up eine nahezu native Leistung, verbrauchte jedoch signifikanten Metaspace und erhöhte die Anlaufzeit der Anwendung um mehrere Sekunden während des Klassenladens und der JIT-Kompilierung. Außerdem fügte es eine Wartungskomplexität für das Debuggen des generierten Codes hinzu.
Reflexion mit Method Handles nutzte die Standard-Method.invoke gefolgt von unreflect, um MethodHandles zu erhalten. Obwohl es einfacher zu implementieren war, führte dies zu Boxing-Kosten für primitive Argumente und verhinderte, dass HotSpot durch die reflektierende Schicht inliner. Leistungstests zeigten eine 10-15x langsamere Weiterleitung im Vergleich zu direkten Aufrufen, wodurch unsere Latenzanforderungen verletzt wurden.
Ausnutzung der polymorphen Signatur erforderte sorgfältiges Casting von Argumenten auf die genau erwarteten Typen, bevor invokeExact aufgerufen wurde. Dadurch konnte der Compiler signatur-spezifische invokevirtual-Anweisungen für jeden Aufrufort generieren, wodurch der MethodHandle effektiv als typisierter Funktionszeiger behandelt wurde. Der Kompromiss war die Strenge der Typen zur Kompilierungszeit – wir mussten die Handler-Signaturen während der Registrierung validieren, um die Typensicherheit zu gewährleisten, und der Code würde nicht kompiliert werden, wenn die Signaturen nicht übereinstimmten.
Ausgewählte Lösung und warum
Wir haben den Ansatz der polymorphen Signatur zusammen mit einer Validierungsschicht zur Registrierungszeit gewählt. Durch die Generierung leichter Adapter-Lambdas (unter Verwendung von LambdaMetafactory und invokedynamic), die genau mit MethodHandle-Signaturen übereinstimmten, erzielten wir direkte Aufrufleistung und gleichzeitig Typensicherheit. Die JVM konnte durch den MethodHandle zur tatsächlichen Handler-Methode inliner, wodurch der Aufwand für die Weiterleitung vollständig beseitigt wurde.
Ergebnis
Das System verarbeitete 2,5 Millionen Ereignisse pro Sekunde mit Sub-Mikrosekunden-Latenz und entsprach der Leistung von handgeschriebenem Dispatch-Code. Der GC-Druck sank um 98 % im Vergleich zum auf Reflexion basierenden Prototyp, da primitive Argumente während des Aufrufpfades kein Boxing mehr erforderten. Die Lösung blieb wartbar, da Typfehler zur Kompilierungszeit und nicht zur Laufzeit erfasst wurden.
Warum erlaubt MethodHandle.invoke() Typkonversion, während invokeExact() eine präzise Signaturübereinstimmung verlangt, obwohl beide polymorphe Signaturen haben?
Beide Methoden tragen die Annotation @PolymorphicSignature, aber invokeExact führt auf dem JVM-Level strenge Signaturprüfungen durch. Wenn der Compiler die invokevirtual-Anweisung für invokeExact generiert, verwendet er die genauen ausgelöschten Typen am Aufrufort. Die JVM überprüft dann, ob diese Typen genau mit dem Ziel-MethodType übereinstimmen. Im Gegensatz dazu umfasst invoke (ohne Exact) Logik, um die Typen am Aufrufort an den Zieltyp unter Verwendung von MethodHandle.asType-Adaptierern anzupassen, die Boxing-, Unboxing- und primitive Konversionen durchführen. Diese Anpassung erfolgt innerhalb der MethodHandle-Implementierung und nicht am Aufrufort, was invoke flexibler, aber potenziell langsamer macht aufgrund des Overheads der Adapterkette.
Wie verhindert die JVM Typ Sicherheitsverletzungen, wenn polymorphe Signaturmethoden willkürliche Methodendeskriptoren erlauben?
Die JVM verlässt sich auf den Java-Compiler, um die Typensicherheit auf der Quellcode-Ebene durchzusetzen. Da @PolymorphicSignature auf Klassen des java.base-Moduls (wie MethodHandle und VarHandle) beschränkt ist, kann Benutzercode keine neuen polymorphen Methoden deklarieren. Der Compiler erlaubt nur polymorphe Aufrufe, bei denen er die Argumenttypen gegen die erwartete Signatur am Aufrufort überprüfen kann. Für invokeExact fügt der Compiler implizite Casts ein, um sicherzustellen, dass der generierte Deskriptor mit dem, was der Programmierer beabsichtigt hat, übereinstimmt. Die JVM vertraut darauf, dass der Compiler diese Überprüfung durchgeführt hat, wodurch es möglich ist, Laufzeitprüfungen des Deskriptors während des Aufrufs zu überspringen und so null Overhead bei gleichzeitiger Aufrechterhaltung von Sicherheit durch Compile-Time-Beschränkungen zu erreichen.
Warum scheinen polymorphe Signaturmethoden in Stack-Traces und beim Debugging auf Typen Object zu erlöschen und werden dennoch mit spezifischen primitiven Typen ausgeführt?
Der javac-Compiler erzeugt das Attribut @PolymorphicSignature in der class-Datei für diese Methoden. Wenn die JVM einen Aufruf zu einer solchen Methode auflöst, ersetzt sie den Deskriptor aus dem konstanten Pool der Aufrufstelle für den deklarierten Deskriptor. Dies bedeutet, dass die tatsächliche Bytecode-Ausführung die spezifischen Typen (int, long usw.) verwendet, aber die Metadaten der Methode im Class-Objekt die deklarierte Signatur (typischerweise (Object...)Object) für Reflexionszwecke beibehalten. Folglich zeigen Stack-Traces die ausgelöschte Form, da Throwable.fillInStackTrace den symbolischen Deskriptor aus den Metadaten der Methode verwendet, nicht den dynamischen Deskriptor, der während des tatsächlichen Aufrufs verwendet wird. Diese Unterscheidung verwirrt Entwickler, die erwarten, die genauen Parametertypen in Debuggern zu sehen.