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

Performance Tuning
#1

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.

#2

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

#3

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

#4

zombie - just wrapper for a future compiled code?

#5

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

#6

[quote]A Zombie method is one that is no longer entrant.
[/quote]
What exactly does that mean?

#7

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

#8

It is JustVoodooMagic ;D

#9

[quote]It is JustVoodooMagic ;D
[/quote]
lol 8)

#10

[quote]Its a method that has been compiled (nmethod, or native method) that is been marked not entrant (enterable) for whatever reason.
[/quote]
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?

#11

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.

#12

Thanks Cliff, that makes everything clear.