-XX:+PrintCompilation - What's a zombie?

[swpalmer]

I was playing around with Mustang b33 and I flipped on the -XX:+PrintCompilation stuff.  (Sometimes it's fun to see what HotSpot is up to.)

After a while I noticed a bunch of lines like this:

522   made zombie  javax.swing.JComponent::paintChildren
551   made zombie  javax.swing.JComponent::_paintImmediately
576   made zombie  java.awt.Component::getGraphics
625   made zombie  com.sun.java.swing.SwingUtilities2::getFontMetrics

These mere methods that had been compiled earlier on in the execution of the program under test.  That first line appeared after the # in the first column had got to 1050.

A while ago someone posted a list somewhere the indicated what all the symbols between the # and the method signature meant (e.g. "!" and "s").  But "made zombie" is something new.

Just what does it mean?

*edit*
More info:
That first line:
522   made zombie  javax.swing.JComponent::paintChildren

was followed a while later by the more typical:
1062  !    javax.swing.JComponent::paintChildren (644 bytes)

and later:
1062   made zombie  javax.swing.JComponent::paintChildren

So it seems the zombies are given life again and then made back into zombies.
Maybe a "zombie" is simply excluded from further consideration for a while so HotSpot can focus on other methods?  I.e. maybe the method is a little too much of a "hot spot" and is dominating the time spent by the HotSpot optimizing code with little actual gains?  Just a guess.

[Azeem Jiva]

So it seems the zombies are given life again and then made back into zombies.
Maybe a "zombie" is simply excluded from further consideration for a while so HotSpot can focus on other methods?  I.e. maybe the method is a little too much of a "hot spot" and is dominating the time spent by the HotSpot optimizing code with little actual gains?  Just a guess.

Nah it's nothing like that, I'm not positive what the "make zombie" is but I'll check when I get to the office Monday

[K.I.L.E.R]

Maybe it has something to do with left over debug code?
This is probably the silliest theory but it has happened before.

Games published by our own members! Check 'em out!

[Raghar]

zombie - just wrapper for a future compiled code?

[Azeem Jiva]

Ahh ok, so here's what happened.  A Zombie method is one that is no longer entrant.  When this happens a native method can be swept by the GC and cleaned up.  The reason it's showing up now, is that the PrintCompilation code was cleaned up to show more information including the "made zombie" bit.  The actual code has always been there, but it's just being displayed as of a few builds ago.  Hope this helpes

[swpalmer]

A Zombie method is one that is no longer entrant.  

What exactly does that mean?

[Azeem Jiva]

What exactly does that mean?

Its a method that has been compiled (nmethod, or native method) that is been marked not entrant (enterable) for whatever reason.

[NVaidya]

It is JustVoodooMagic  

[Jeff]

It is JustVoodooMagic  

lol

[swpalmer]

Its a method that has been compiled (nmethod, or native method) that is been marked not entrant (enterable) for whatever reason.

That's what I thought.  I just can't see the circumstance in which it applies.  E.g. above I show paintComponent as the method and I just don't understand how paintComponent would no longer be "enterable"  (all of the UI is still visible throughout my test)

Perhaps I just need more coffee... or I'm oversimplifying.  

Is it correct to equate non-entrant with respect to methods as an equivalent of 'unreachable' with respect to objects?

Games published by our own members! Check 'em out!

[cliffc]

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.

[swpalmer]

Thanks Cliff,  that makes everything clear.