In che modo jProfiler gestisce JIT?

Question

Uso jProfiler ampiamente ed è un ottimo strumento, ma mi chiedo come sia jProfiler gestire gli effetti della compilation JIT.

Sono in grado di osservare ad esempio il metodo inlining? Se un metodo è in linea, non sarà visibile nell'istantanea o jProfiler è ancora in grado di calcolare il tempo di esecuzione?

Analogamente, un metodo che non ha effetti collaterali e può essere completamente ottimizzato non verrà visualizzato anche nel jProfiler. È corretto?

Di solito profilo le mie applicazioni dopo un lungo periodo di riscaldamento quindi mi aspetto che il codice sia JIT-ed/ottimizzato laddove possibile. Pertanto, i metodi che sospetto dovrebbero essere ottimizzati e sono ancora visibili nel profilo sono sempre un grande mistero per me.

Answer 1

Uso jProfiler in modo estensivo ed è un ottimo strumento, ma mi chiedo in che modo jProfiler gestisca gli effetti della compilation JIT.

La compilazione just-in-time è in realtà una tecnologia piuttosto vecchia che è stata sostituita con l'ottimizzatore adattivo HotSpot. Una JIT compila ciecamente ogni metodo dal codice bytecode Java nel codice nativo e può (o non può) essere in grado di ottimizzarlo bene.

Tuttavia, un ottimizzatore adattivo esamina il modo in cui il codice viene eseguito al momento e ottimizza solo il codice che viene eseguito più spesso. Poiché l'ottimizzatore è a conoscenza di del modo in cui viene utilizzato il codice, l'ottimizzatore può e fa un metodo migliore di inlining, previsione di branche, lock grossolanamente, loop unwinding e altro.

Sono in grado di osservare ad esempio il metodo di inlining? Se un metodo è in linea, non sarà visibile nell'istantanea o jProfiler è ancora in grado di calcolare il tempo di esecuzione?

JProfiler non segnalerà quali metodi sono stati in linea; tuttavia, segnalerà felicemente le loro invocazioni, anche se il compilatore li ha posizionati in linea in un altro metodo.

Come? Bene, durante la compilazione, il compilatore demarca i limiti del metodo nel codice nativo. Questo è essenziale affinché JVM sia in grado di ricostruire una traccia dello stack quando si verifica un'eccezione o un errore. Quando viene campionata la JVM, la JVM risponde con le tracce di stack dei thread in esecuzione e quindi il metodo corrente viene riportato in modo accurato, anche se era in linea.

Analogamente, un metodo che non ha effetti collaterali e può essere completamente ottimizzato non verrà visualizzato nel jProfiler. È corretto?

Sei quasi corretto. Un metodo senza effetti collaterali o valore di ritorno calcolato o chiamata a un altro metodo con un possibile effetto collaterale è quasi completamente ottimizzato, ma c'è un residuo di fossili nella JVM che registra che il metodo sarebbe stato.L'overhead marginale è estremamente piccolo, ma ha le seguenti caratteristiche interessanti:

1. Quando campionamento, è altamente improbabile che questo metodo sarà mai sullo stack al momento del campionamento, quindi molto probabilmente non sarà rilevato da jProfiler (o altri profiler del campionamento).
2. Quando strumentazione, il profiler tracce tutte le chiamate di metodo e sarà rilevare la chiamata al metodo. Il costo totale sarà, come detto sopra, banalmente piccolo.

La differenza nel campionamento rispetto allo strumentazione è spiegata in this article.