Output java PrintCompilation: qual è il significato di "made not entrant" e "made zombie"

Question

Quando si esegue un'applicazione Java 1.6 (1.6.0_03-b05), ho aggiunto il flag -XX:+PrintCompilation. Sull'output di alcuni metodi, in particolare alcuni di quelli che so vengono chiamati molto, vedo il testo made not entrant e made zombie.

Cosa significano? La migliore ipotesi è che si tratta di un passaggio di decompilazione prima di ricompilare il metodo o una dipendenza con una maggiore ottimizzazione. È vero? Perché "zombie" e "entrante"?

esempio, con un po 'di tempo tra alcune di queste linee:

[... near the beginning] 
42  jsr166y.LinkedTransferQueue::xfer (294 bytes) 

[... much later] 
42 made not entrant jsr166y.LinkedTransferQueue::xfer (294 bytes) 
--- n sun.misc.Unsafe::compareAndSwapObject 
170  jsr166y.LinkedTransferQueue::xfer (294 bytes) 
170 made not entrant jsr166y.LinkedTransferQueue::xfer (294 bytes) 
    4%  jsr166y.LinkedTransferQueue::xfer @ 29 (294 bytes) 
171  jsr166y.LinkedTransferQueue::xfer (294 bytes) 

[... even later] 
42 made zombie jsr166y.LinkedTransferQueue::xfer (294 bytes) 
170 made zombie jsr166y.LinkedTransferQueue::xfer (294 bytes) 
171 made not entrant jsr166y.LinkedTransferQueue::xfer (294 bytes) 
172  jsr166y.LinkedTransferQueue::xfer (294 bytes) 

[... no further logs] 

Answer 1

Ho raccolto alcune informazioni su questo my blog. Un commento di Cliff Cliff che ho trovato dice:

I metodi di zombie sono metodi il cui codice è stato reso non valido dal caricamento della classe. Generalmente il compilatore del server prende decisioni aggressive inline di metodi non definitivi. Finché il metodo inline non viene mai sovrascritto, il codice è corretto. Quando viene caricata una sottoclasse e il metodo viene sovrascritto, il codice compilato viene interrotto per tutte le chiamate future. Il codice viene dichiarato "non entrante" (nessun futuro chiamante per il codice non funzionante), ma a volte i chiamanti esistenti possono continuare a utilizzare il codice. Nel caso di inlining, non è abbastanza buono; i frame di stack dei chiamanti esistenti vengono "deottimizzati" quando ritornano al codice da chiamate nidificate (o solo se sono in esecuzione nel codice). Quando nessun altro stack frame tiene il PC nel codice spezzato, viene dichiarato "zombi" - pronto per essere rimosso una volta che il GC si avvicina.

Answer 2

Questo non è assolutamente un area di competenza per me, ma mi interessava e così ha fatto un po' di scavo.

Un paio di collegamenti che potresti trovare interessanti: OpenJDK:nmethod.cpp, OpenJDK:nmethod.hpp.

Un estratto di nmethod.hpp:

// Make the nmethod non entrant. The nmethod will continue to be 
// alive. It is used when an uncommon trap happens. Returns true 
// if this thread changed the state of the nmethod or false if 
// another thread performed the transition. 
bool make_not_entrant() { return make_not_entrant_or_zombie(not_entrant); } 
//... 

Proprio come un punto di partenza.

Answer 3

Here is a Gist con una quantità incredibile di informazioni su PrintCompilation. In particolare, si dice:

Quando deoptimization accade, se si decide di invalidare l'incriminato nmethod, sarà "non fatto entrante" prima; e poi, quando lo NMethodSweeper trova che non ci sono più attivazioni sugli stack, è "made zombie";