Quali sono le differenze in JIT tra Java and.Net

Sono bestie molto diverse. Come le persone hanno sottolineato, il CLR compila il codice macchina prima di eseguire un pezzo di MSIL. Ciò consente oltre alla tipica eliminazione del codice morto e all'inlining delle ottimizzazioni private di sfruttare la particolare architettura della CPU della macchina di destinazione (anche se non sono sicuro che lo faccia). Questo comporta anche un successo per ogni classe (anche se il compilatore è abbastanza veloce e molte librerie di piattaforme sono solo uno strato sottile su Win32 API).

La VM HotSpot sta adottando un approccio diverso. Stabilisce che la maggior parte del codice viene eseguita raramente, quindi non vale la pena dedicare del tempo alla compilazione. Tutto il bytecode inizia in modalità interpretata. La VM mantiene le statistiche nei siti di chiamata e cerca di identificare i metodi che vengono chiamati più di un numero predefinito di volte. Quindi compila solo questi metodi con un compilatore JIT veloce (C1) e scambia il metodo mentre è in esecuzione (questa è la salsa speciale di HS). Dopo il C1-compilato il metodo è stato invocato altre volte, lo stesso metodo viene compilato con un compilatore lento ma sofisticato e il codice viene nuovamente scambiato al volo.

Poiché HotSpot può scambiare metodi mentre sono in esecuzione, i compilatori VM possono eseguire alcune ottimizzazioni speculative che non sono sicure nel codice compilato staticamente. Un esempio canonico è la spedizione statica / inlining di chiamate monomorfe (metodo polimorfico con una sola implementazione). Questo viene fatto se la VM vede che questo metodo sempre risolve lo stesso obiettivo. Quello che era l'invocazione complessa è ridotto a poche istruzioni della CPU, che sono previste e pipeline dalle moderne CPU. Quando la condizione di guardia smette di essere vera, la VM può prendere un percorso di codice diverso o addirittura tornare alla modalità di interpretazione. Sulla base delle statistiche e del carico di lavoro del programma, il codice macchina generato può essere diverso in tempi diversi. Molte di queste ottimizzazioni si basano sulle informazioni raccolte durante l'esecuzione del programma e non sono possibili se si compila una volta che si carica la classe.

Questo è il motivo per cui è necessario riscaldare la JVM ed emulare il carico di lavoro realistico quando si esegue il benchmark degli algoritmi (i dati distorti possono portare a valutazioni non realistiche delle ottimizzazioni). Altre ottimizzazioni sono lock elision, adaptive spin-locking,escape analysis e stack allocation, ecc.

Detto questo, HotSpot è solo una delle macchine virtuali. JRockit, Azul, J9 di IBM e RVM ripristinabile, hanno tutti profili di prestazioni diversi.