Quali sono le differenze in JIT tra Java e .Net

Question

So che Microsoft .NET utilizza CLR come compilatore JIT mentre Java ha l'hotspot. Quali sono le differenze tra loro?

Answer 1

Sono animali molto diversi. Come hanno sottolineato le persone, il CLR si compila sul codice macchina prima di eseguire un pezzo di MSIL. Ciò consente, oltre all'eliminazione del codice morto tipica e all'integrazione delle ottimizzazioni dei privati, per sfruttare la particolare architettura della CPU della macchina di destinazione (anche se non sono sicuro che lo faccia). Ciò comporta anche un hit per ogni classe (anche se il compilatore è abbastanza veloce e molte librerie di piattaforme sono solo un sottile strato sopra l'API Win32).

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 a compilarlo. Tutto il bytecode inizia in modalità interpretata. La VM mantiene statistiche sui siti di chiamata e cerca di identificare metodi che sono chiamati più di un numero predefinito di volte. Quindi compila solo questi metodi con un veloce compilatore JIT (C1) e scambia il metodo mentre è in esecuzione (questa è la salsa speciale di HS). Dopo che il metodo C1-compilato è stato richiamato alcune volte, lo stesso metodo viene compilato con un compilatore lento ma sofisticato e il codice viene nuovamente sostituito al volo.

Poiché HotSpot può scambiare i metodi mentre sono in esecuzione, i compilatori VM possono eseguire alcune ottimizzazioni speculative non sicure nel codice compilato in modo statico. Un esempio canonico è il dispatch/inlining statico di chiamate monomorfiche (metodo polimorfico con una sola implementazione). Questo viene fatto se la VM vede che questo metodo si risolve sempre sullo stesso target. Quella che prima era una chiamata complessa è ridotta a poche protezioni per le istruzioni della CPU, che sono previste e sottoposte a 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. In base alle statistiche e al carico di lavoro del programma, il codice macchina generato può essere diverso in momenti 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.

Ecco perché è necessario riscaldare la JVM ed emulare il carico di lavoro realistico quando si parametrizzano gli algoritmi (i dati distorti possono portare a valutazioni non realistiche delle ottimizzazioni). Altre ottimizzazioni sono elisione di blocco, blocco dello spin adattivo, analisi di fuga e allocazione dello stack, ecc.

Detto questo, HotSpot è solo una delle VM. JRockit, Azul, IBM J9 e Resettable RVM, - hanno tutti profili di prestazione diversi.