Che cos'è l'ottimizzazione della de-reflection in HotSpot JIT e come viene implementato?

Question

Guardando Towards a Universal VM presentazione, ho studiato questa diapositiva, che elenca tutte le ottimizzazioni che HotSpot JIT fa:

Nella sezione language-specific techniques c'è una de-riflesso. Ho provato a trovare alcune informazioni su Internet, ma non ci sono riuscito. Ho capito che questa ottimizzazione elimina in qualche modo i costi di riflessione, ma sono interessato ai dettagli. Qualcuno può chiarirlo o dare qualche link utile?

Answer 1

Sì, c'è un ottimizzazione per ridurre i costi di Reflection, sebbene sia implementato principalmente in Class Library piuttosto che in JVM.

Prima di Java 1.4 Method.invoke ha funzionato tramite una chiamata JNI a VM runtime. Ogni invocazione richiedeva almeno due transizioni da Java a Nativo e viceversa. Il runtime di VM ha analizzato una firma del metodo, verificato che i tipi di argomenti passati erano corretti, eseguito il boxing/unboxing e costruito un nuovo frame Java per un metodo chiamato. Tutto ciò era piuttosto lento.

Poiché Java 1.4 Method.invoke utilizza la generazione dinamica del codice byte se un metodo viene chiamato più di 15 volte (configurabile tramite la proprietà di sistema sun.reflect.inflationThreshold). Una classe Java speciale responsabile per chiamare il particolare metodo dato è costruita in fase di esecuzione. Questa classe implementa sun.reflect.MethodAccessor a cui chiamate di delegazioni java.lang.reflect.Method.

L'approccio con la generazione di bytecode dinamica è molto più veloce dato che

• non soffre di JNI in testa;
• non è necessario analizzare la firma del metodo ogni volta, poiché ogni metodo richiamato tramite Reflection ha il proprio MethodAccessor univoco;
• può essere ulteriormente ottimizzato, ad es. questi MethodAccessors possono beneficiare di tutte le ottimizzazioni JIT regolari come inline, costante di propagazione, autoboxing eliminazione ecc

nota, che questa ottimizzazione è implementato per lo più in Java code senza assistenza JVM. L'unica cosa che HotSpot VM fa per rendere possibile questa ottimizzazione - sta saltando la verifica bytecode per tali MethodAccessor generati. Altrimenti il ​​verificatore non consentirebbe, ad esempio, di chiamare metodi privati.