java PrintCompilation 输出:“made not entrant”的含义是什么?和“制造僵尸”
运行 Java 1.6 (1.6.0_03-b05) 应用程序时,我添加了 -XX:+PrintCompilation
标志。在某些方法的输出中,特别是我知道经常被调用的一些方法,我看到文本 made not entrant
和 made Zombie
。
这些是什么意思?最好的猜测是,这是重新编译该方法或具有更大优化的依赖项之前的反编译步骤。这是真的吗?为什么是“僵尸”和“进入者”?
例如,其中一些行之间有相当多的时间:
[... 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]
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]
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我在我的博客上整理了一些相关信息。我发现的悬崖点击评论说:
I've pulled together some info on this on my blog. A Cliff Click comment I found says:
这对我来说绝对不是一个专业领域,但我很感兴趣,所以做了一些挖掘。
您可能会发现一些有趣的链接: OpenJDK:nmethod.cpp,OpenJDK:nmethod.hpp。
nmethod.hpp
的摘录:只是作为一个起点。
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
:Just as a starting place.
一个较新的解释是,日志中可以有这样的条目:
这实际上意味着在 第 3 层,然后在层下
4
已进一步优化,并且已不再进入 3-d 层;这意味着它将被第四层的代码替换。A newer explanation is that there can be entries like this in log:
This actually means that one method (
second
here) has been compiled under tier level 3, then under tier level4
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.这里有一个要点,其中包含有关
PrintCompilation
的大量信息。具体来说,它说:Here is a Gist with an unbelievable amount of information on
PrintCompilation
. Specifically, it says: