Circa la dinamica de-ottimizzazione di HotSpot

Question

Quando ho letto il libro di "Scala di profondità", si informa che HotSpot compilatore ha diverse caratteristiche importanti, uno di loro è "Dynamic De-ottimizzazione":

e 'la capacità di determinare se un'ottimizzazione fatto non, infatti, migliorare le prestazioni e disfare che l'ottimizzazione, permettendo ad altri di essere applicati

sembra HotSpot cercherà tutti i tipi di s "ottimizzazione" e scegliere il migliore di loro.

Ma non lo capisco. L'ottimizzazione qui è fornita da HotSpot? Intendo che i programmatori cercano spesso di ottimizzare il codice con alcune competenze, che HotSpot gestirà?

E c'è qualche "ottimizzazione" comune che HotSpot proverà?

Answer 1

Un "ottimizzazione del compilatore" è una trasformazione del codice nel tentativo di renderlo migliore in un certo senso - in genere, richiede meno tempo per l'esecuzione. Lo Wikipedia article on optimizing compilers ha una buona lista delle ottimizzazioni comuni prese; il compilatore Hotspot JIT probabilmente li fa tutti e molto altro.

Quindi il libro significa che Hotspot applicherà alcune di queste tecniche al codice, vedere se migliora il tempo di esecuzione e, in caso contrario, lo ripristinerà.

Come hai giustamente affermato, il processo di modifica manuale del codice per renderlo migliore viene anche chiamato "ottimizzazione" o "ottimizzazione manuale". Il compilatore tenta di applicare il maggior numero possibile di ottimizzazioni, ma molte modifiche possibili devono ancora essere applicate manualmente. Ancora una volta, Wikipedia has a solid article about what a program optimization is.

Answer 2

Le ottimizzazioni di HotSpot sono di tipo diverso rispetto a quello che gli sviluppatori fanno a livello di codice sorgente Java, sebbene alcune di esse abbiano lo stesso effetto netto.

Questa è una parte dell'arsenale del compilatore JIT:

• chiamata al metodo inline;
• sollevamento di valori fuori da un loop;
• siti di chiamata monomorfici;
• posizionamento di oggetti sullo stack, soggetto a Escape Analysis;
• variabili vincolanti per i registri CPU;
• elisione di blocco.

La parte più interessante è la sinergia tra alcune ottimizzazioni, quali:

1. un sito chiamata viene implementato come monomorfico;
2. ciò consente l'inlining del metodo;
3. che invita il posizionamento dello stack di un oggetto;
4. che consente di associare i campi dell'oggetto ai registri.

Il tuo preventivo, tuttavia, è il meglio delle mie conoscenze sbagliato. Il codice ottimizzato non comporta alcun auto-profiling perché lo rallenterebbe.L'unica condizione per la deottimizzazione è la violazione delle ipotesi ottimistiche secondo le quali il codice era compilato JIT. Esempio: un determinato sito di chiamata al metodo riceve solo un tipo di oggetto, si specializza su quell'oggetto (compilato come sito di chiamata monomorfico), ma poi, più tardi, appare un tipo di oggetto diverso. Ora il codice ottimizzato non può essere eseguito e deve essere deottimizzato.

Answer 3

Oracle fornisce un (rather concise) summary of this performance techniques applied by the JVM. Spiega:

La deoptimizzazione è il processo di modifica di uno stack frame ottimizzato a non ottimizzato. Per quanto riguarda i metodi compilati, è anche il processo di buttare via il codice con ottimizzazioni ottimistiche non valide, e sostituirlo con un codice meno ottimizzato e più robusto. Un metodo può essere decapitato nel principio dozzine di volte.

In questa sintesi, le ragioni di deoptimization sono elencati come segue:

1. Il compilatore può spegnere un ramo non godute e deoptimize se è mai preso.
2. Analogamente per i controlli di sicurezza di basso livello che storicamente non hanno mai fallito.
3. Se un sito di chiamata o un cast incontrano un tipo non previsto, il compilatore non si adatta.
4. Se viene caricata una classe che invalida una precedente analisi della gerarchia delle classi, qualsiasi attivazione del metodo interessata, in qualsiasi thread, viene forzata in un punto di sicurezza e non ottimizzata.
5. Tale deoptimizzazione indiretta è mediata dal sistema di dipendenza. Se il compilatore fa un'ipotesi non controllata, deve registrare una dipendenza controllabile . (Ad esempio, che la classe Foo non ha sottoclassi, o metodo Foo.bar è non ha sostituzioni.)

Personalmente, ho trovato this blog entry su micro-analisi comparativa abbastanza leggibile che copre anche i temi della ottimizzazione e deoptimization sulla macchina virtuale HotSpot. Inoltre, posso consigliare reading through this presentation.