Perché non vengono visualizzati tutti i metodi nel profiler VisualVM?

Question

Sto usando VisualVM per vedere dove la mia applicazione è lenta. Ma non mostra tutti i metodi, probabilmente non mostra tutti i metodi che ritarda l'applicazione.

Possiedo un'applicazione realtime (elaborazione del suono) e una mancanza di tempo in poche centinaia di microsecondi.

È possibile che VisualVM nasconda metodi che sono veloci essi stessi?

UPDATE 1

Ho trovato metodo lento dal campionatore e indovinare. Era il metodo toString() che veniva chiamato dalla registrazione di debug disattivata ma che consumava un tempo.

Settings aiutato e ora so come vederlo: era in base all'opzione Start profiling from.

Answer 1

Al momento non ce l'ho davanti, ma prima di iniziare la creazione del profilo, c'è un riquadro delle impostazioni nascosto per impostazione predefinita e che consente di immettere espressioni regolari per filtrare i metodi. Di default, filtra molte delle cose JDK di base.

Answer 2

Altro che i filtri citati da Ryan Stewart, qui ci sono un paio di altri motivi per cui metodi non possono essere visualizzati nel profiler:

• profili di campionamento sono intrinsecamente stocastico: un campione della pila attuale tutti i thread sono presi ogni N ms. Alcuni metodi che sono stati effettivamente eseguiti ma che non vengono catturati in nessun campione durante la tua corsa non appariranno. Questo in genere non è troppo problematico poiché il fatto stesso che non appaiono in alcun campione, significa che con probabilità molto alta questi sono metodi che non occupano gran parte del tempo di esecuzione.
• Quando si utilizza il campionamento basato sulla strumentazione in visualvm (chiamato "CPU profiling"), è necessario definire il punto di ingresso per i metodi profilati (l'opzione "Inizia profilazione da"). Ho trovato questo fallisce per i metodi nel pacchetto di default, e inoltre non prenderò tempo nei metodi che sono in esecuzione in esecuzione quando il profiler è collegato (per la durata del richiamo corrente - otterrà invocazioni successive. Questo è probabilmente perché il metodo strumentato non verrà sostituito fino al termine dell'invocazione attuale
• Il campionamento è soggetto a un problema potenzialmente grave con la profilazione basata su traccia stack, ovvero che i campioni vengono prelevati solo nei punti sicuri del codice. richiesto, ogni thread viene forzato in un punto sicuro, quindi viene preso lo stack. In alcuni casi è possibile che vi sia un punto caldo nel codice che non esegue il polling sicuro dei punti (comune per i loop semplici che il JIT può garantire terminare dopo un numero fisso di iterazioni), interlacciata con un po 'di codice che ha un sondaggio safepoint. I tuoi stack mostreranno sempre il tuo processo nel codice di sicurezza, mai nella cassaforte-poi nt codice libero, anche se quest'ultimo potrebbe richiedere la maggior parte del tempo di CPU.