java PrintCompilation output: quelle est la signification de "made not entrant" et "made zombie"

Question

Lors de l'exécution de Java 1.6 (1.6.0_03-b05) app j'ai ajouté l' -XX:+PrintCompilation drapeau. À la sortie, pour certaines méthodes, en particulier de certains de ceux que je connais sont appelé beaucoup de choses, je vois le texte made not entrant et made zombie.

Que veulent-ils dire? Meilleure supposition est que c'est une décompilation étape avant de recompiler soit la méthode ou d'une dépendance avec une plus grande optimisation. Est-ce vrai? Pourquoi "zombie" et "participant"?

Exemple, avec un peu de temps entre certains de ces lignes:

[... 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]

Plus: quelques brèves informations en expliquant certains des symboles dans cette sortie. Aussi n signifie natif.

Answer 1

J'ai rassemblé quelques infos sur ce sur mon blog. Une Falaise Cliquez sur commentaire que j'ai trouvé, dit:

Zombie méthodes sont des méthodes dont le code a été rendue caduque par la classe de chargement. Généralement, le serveur compilateur rend agressive inline décisions de non-finale méthodes. Tant que le inline méthode n'est jamais remplacé le code est correct. Lorsqu'une sous-classe est chargé et la méthode substituée, le code compilé est rompu pour tous les futurs appels à elle. Le code est déclaré "non participant" (pas d'avenir, les appelants vers le code cassé), mais parfois existantes, les appelants peuvent continuer à utiliser le code. Dans le cas de l'in-lining, ce n'est pas suffisant; les appelants de la pile d'images sont "deoptimized" lorsqu'ils reviennent sur le code à partir d'appels imbriqués (ou tout simplement si ils sont en cours d'exécution dans le code). Lorsque plus aucune pile cadres détiennent PC dans le code cassé, il est déclaré "zombie" - prêt pour l'enlèvement une fois que le GC est à elle.

Answer 2

Ce n'est absolument pas un domaine d'expertise pour moi, mais j'ai été intéressé et donc fait un peu de creuser.

Un couple de liens que vous pourriez trouver intéressant: OpenJDK:nmethod.cpp, OpenJDK:nmethod.hpp.

Un extrait de l' 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); }
//...

Tout comme un point de départ.