45

When running a Java 1.6 (1.6.0_03-b05) app I've added the -XX:+PrintCompilation flag. On the output for some methods, in particular some of those that I know are getting called a lot, I see the text made not entrant and made zombie.

What do these mean? Best guess is that it's a decompilation step before recompiling either that method or a dependency with greater optimisation. Is that true? Why "zombie" and "entrant"?

Example, with quite a bit of time between some of these lines:

[... 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]
rolve
  • 10,083
  • 4
  • 55
  • 75
Joe Kearney
  • 7,397
  • 6
  • 34
  • 45

4 Answers4

25

I've pulled together some info on this on my blog. A Cliff Click comment I found says:

Zombie methods are methods whose code has been made invalid by class loading. Generally the server compiler makes aggressive inlining decisions of non-final methods. As long as the inlined method is never overridden the code is correct. When a subclass is loaded and the method overridden, the compiled code is broken for all future calls to it. The code gets declared "not entrant" (no future callers to the broken code), but sometimes existing callers can keep using the code. In the case of inlining, that's not good enough; existing callers' stack frames are "deoptimized" when they return to the code from nested calls (or just if they are running in the code). When no more stack frames hold PC's into the broken code it's declared a "zombie" - ready for removal once the GC gets around to it.

JodaStephen
  • 60,927
  • 15
  • 95
  • 117
  • 8
    Kris Mok wrote a reply to JodaStephen, which is now linked from his blog and is even more complete in its description of -XX:+PrintCompilation; here's the link: https://gist.github.com/1165804#file_notes.md – Blaisorblade Nov 16 '11 at 18:15
9

This is absolutely not an area of expertise for me, but I was interested and so did a bit of digging.

A couple of links you might find interesting: OpenJDK:nmethod.cpp, OpenJDK:nmethod.hpp.

A excerpt of 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); }
//...

Just as a starting place.

Mark Peters
  • 80,126
  • 17
  • 159
  • 190
  • That's a useful start, thanks. The more I look into the code the more hotspot vocabulary I find I don't know! So do we think "not_entrant" simply means "don't execute this compiled code again, need to de-opt/recompile first"? Another link: see line 536 of http://www.google.com/codesearch/p?hl=en#aRIt9pqzOVI/src/share/vm/oops/methodOop.cpp – Joe Kearney Jun 03 '10 at 13:33
  • 4
    Given the meaning of "entrant" my *guess* would be that it flags the compiled method to not be *entered* again (though some threads may still be in it) while zombie means that it has no further use and can be disposed of. Just like a checkout counter could announce it's not accepting new customers (non-entrant) but would still have to service the queued customers before closing the till (zombie). But it's just a guess. – Mark Peters Jun 03 '10 at 14:22
9

A newer explanation is that there can be entries like this in log:

129   72       3       EscapeAnalysysTest::second (24 bytes)
.......... some more lines
135   76       4       EscapeAnalysysTest::second (24 bytes)
137   74       3       EscapeAnalysysTest::second (24 bytes)   made not entrant

This actually means that one method (second here) has been compiled under tier level 3, then under tier level 4 it has been further more optimized and it has been made not entrant for the 3-d tier; meaning it will be replaced with code from the 4-th tier.

Eugene
  • 117,005
  • 15
  • 201
  • 306
  • could you kindly give me the source of this explanation? – merovingienne Jul 16 '18 at 13:00
  • 1
    @merovingienne that is what I remember while reading jvm source code, I don't remember the exact path now... – Eugene Jul 16 '18 at 13:01
  • 1
    @merovingienne You can find very useful information about Java JIT in the talk by Douglas Hawkins: [Understanding the Tricks Behind the JIT](https://www.youtube.com/watch?v=oH4_unx8eJQ) . He explains "made not entrant" at 20:30. – Jerry Lundegaard Feb 22 '21 at 15:55
3

Here is a Gist with an unbelievable amount of information on PrintCompilation. Specifically, it says:

When deoptimization happens, if it is decided to invalidate the offending nmethod, it will be "made not entrant" first; and then, when the NMethodSweeper finds that there are no activations of it on the stacks any more, it is "made zombie";

rolve
  • 10,083
  • 4
  • 55
  • 75