Storia della domanda
L'introduzione di invokedynamic in Java 7 tramite JSR 292 ha portato l'API MethodHandle a supportare implementazioni di linguaggi dinamici sulla JVM. La sfida consisteva nel fatto che MethodHandle.invoke doveva accettare qualsiasi combinazione di tipi di argomento e tipi di ritorno senza dichiarare mille overload. Gli architetti della JVM hanno risolto questo introducendo il concetto di metodi con firma polimorfica, contrassegnati internamente dall'annotazione @PolymorphicSignature all'interno del pacchetto java.lang.invoke.
Il problema
L'invocazione standard di un metodo in Java richiede che il compilatore emetta un'istruzione invokevirtual (o simile) facendo riferimento a un descrittore di metodo specifico nel pool costanti che corrisponde esattamente alla firma dichiarata del metodo. Se MethodHandle.invoke fosse dichiarato per accettare Object... args, ogni call site richiederebbe boxing e allocazione di array, vanificando gli obiettivi di prestazioni. Al contrario, dichiarare overload per ogni possibile combinazione di firma è impossibile e farebbe aumentare indefinitamente il file Class.
La soluzione
La JVM tratta i metodi annotati con @PolymorphicSignature in modo speciale. Quando il compilatore si imbatte in una chiamata a un metodo del genere, ignora la firma dichiarata e genera invece un'istruzione invokevirtual il cui descrittore di metodo corrisponde esattamente ai tipi cancellati degli argomenti e al tipo di ritorno nel call site. Questo consente a MethodHandle.invokeExact di apparire come se accettasse (Object)Object nel codice sorgente ma di compilarsi in (String)int in un call site specifico. La JVM collega quindi direttamente questa chiamata al punto di ingresso del metodo target senza sovraccarico dell'adattatore.
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)); // Il compilatore genera invokevirtual con descrittore (String)int // nonostante invokeExact sia dichiarato come (Object)Object nel bytecode int result = (int) handle.invokeExact("hello"); System.out.println(result); // Stampa: 5 } }
Descrizione del problema
Durante la costruzione di un framework di elaborazione eventi ad alta capacità per dati di tick finanziari, avevamo bisogno di inviare messaggi in arrivo a gestori registrati utilizzando una flessibilità simile alla reflection ma senza sovraccarico di allocazione. Ogni metodo gestore aveva firme diverse—alcuni accettavano timestamp long, altri prezzi BigDecimal—rendendo difficile l'invio generico senza boxing dei primitivi.
Diverse soluzioni considerate
La generazione dinamica di bytecode ha comportato l'uso di ASM o ByteBuddy per generare classi proxy per ogni firma di gestore al momento della registrazione. Questo approccio offriva prestazioni quasi native dopo il riscaldamento ma consumava una quantità significativa di Metaspace e aumentava la latenza di avvio dell'applicazione di alcuni secondi durante il caricamento delle classi e la compilazione JIT. Ha inoltre aggiunto complessità di manutenzione per il debugging del codice generato.
La reflection con i metodi handle ha utilizzato Method.invoke standard seguito da unreflect per ottenere i MethodHandle. Sebbene fosse più semplice da implementare, questo imponeva costi di boxing per gli argomenti primitivi e impediva a HotSpot di inlining attraverso il layer riflessivo. I test delle prestazioni hanno mostrato un invio 10-15 volte più lento rispetto alle chiamate dirette, violando i nostri requisiti di latenza.
Lo sfruttamento della firma polimorfica richiedeva di fare attenzione a castare gli argomenti ai tipi esatti attesi prima di chiamare invokeExact. Questo consentiva al compilatore di generare istruzioni invokevirtual specifiche per la firma per ogni call site, trattando effettivamente il MethodHandle come un puntatore a funzione tipizzato. Il compromesso era la rigore del tipo a tempo di compilazione—dovevamo convalidare le firme dei gestori durante la registrazione per garantire la sicurezza del tipo, e il codice non si sarebbe compilato se le firme non corrispondevano.
Soluzione scelta e perché
Abbiamo selezionato l'approccio della firma polimorfica combinato con un layer di convalida al momento della registrazione. Generando leggeri lambda adattatori (utilizzando LambdaMetafactory e invokedynamic) che corrispondevano esattamente alle firme MethodHandle, abbiamo ottenuto prestazioni di chiamata diretta mantenendo la sicurezza dei tipi. La JVM poteva in-line attraverso il MethodHandle fino al metodo gestore reale, eliminando completamente il sovraccarico di invio.
Risultato
Il sistema ha elaborato 2,5 milioni di eventi al secondo con latenza sub-microsecondo, corrispondendo alle prestazioni del codice di invio scritto a mano. La pressione del GC è diminuita del 98% rispetto al prototipo basato su reflection, in quanto gli argomenti primitivi non richiedevano più boxing durante il percorso di invocazione. La soluzione è rimasta mantenibile perché gli errori di tipo venivano rilevati a tempo di compilazione anziché a tempo di esecuzione.
Perché MethodHandle.invoke() consente la conversione di tipo mentre invokeExact() richiede una corrispondenza precisa della firma nonostante entrambi abbiano firme polimorfiche?
Entrambi i metodi portano l'annotazione @PolymorphicSignature, ma invokeExact esegue un controllo rigoroso della firma a livello di JVM. Quando il compilatore genera l'istruzione invokevirtual per invokeExact, utilizza i tipi esatti cancellati nel call site. La JVM verifica quindi che questi tipi corrispondano esattamente al MethodType target. Al contrario, invoke (senza Exact) include logiche per adattare i tipi del call site al tipo target utilizzando adattatori MethodHandle.asType, che eseguono boxing, unboxing e conversioni primitive. Questo adattamento avviene all'interno dell'implementazione di MethodHandle piuttosto che nel call site, rendendo invoke più flessibile ma potenzialmente più lento a causa del sovraccarico della catena dell'adattatore.
Come fa la JVM a prevenire le violazioni della sicurezza dei tipi se i metodi con firma polimorfica consentono descrittori di metodo arbitrari?
La JVM si affida al compilatore Java per far rispettare la sicurezza dei tipi a livello di sorgente. Poiché @PolymorphicSignature è limitato alle classi del modulo java.base (come MethodHandle e VarHandle), il codice utente non può dichiarare nuovi metodi polimorfici. Il compilatore consente solo chiamate polimorfiche dove può verificare i tipi degli argomenti rispetto alla firma attesa nel call site. Per invokeExact, il compilatore inserisce cast impliciti per garantire che il descrittore generato corrisponda a quanto inteso dal programmatore. La JVM si fida che il compilatore abbia eseguito questa verifica, consentendole di saltare i controlli di descrittore a tempo di esecuzione durante l'invocazione, ottenendo in tal modo zero sovraccarico mantenendo la sicurezza tramite vincoli a tempo di compilazione.
Perché i metodi con firma polimorfica sembrano cancellarsi a tipi Object nelle tracce dello stack e nel debugging, ma vengono eseguiti con tipi primitivi specifici?
Il compilatore javac emette l'attributo @PolymorphicSignature nel file class per questi metodi. Quando la JVM risolve un'invocazione a un metodo del genere, sostituisce il descrittore dall'entrata del pool costanti del call site per il descrittore dichiarato. Ciò significa che l'esecuzione effettiva del bytecode usa i tipi specifici (int, long, ecc.), ma i metadati del metodo nell'oggetto Class mantengono la firma dichiarata (tipicamente (Object...)Object) per scopi di riflessione. Di conseguenza, le tracce dello stack mostrano la forma cancellata perché Throwable.fillInStackTrace utilizza il descrittore simbolico dai metadati del metodo, non il descrittore dinamico utilizzato durante l'invocazione effettiva. Questa distinzione confonde gli sviluppatori che si aspettano di vedere i tipi di parametro esatti nei debugger.