JVM 崩溃日志中的 BufferBlob::Interpreter 是啥意思？

Posted 2023-04-15

【中文标题】JVM 崩溃日志中的 BufferBlob::Interpreter 是啥意思？

【英文标题】：What does BufferBlob::Interpreter in JVM crash log mean?JVM 崩溃日志中的 BufferBlob::Interpreter 是什么意思？

【发布时间】：2011-12-17 06:09:10

【问题描述】：

我正在调查我的应用程序中偶尔发生的 JVM 崩溃。 hs_err 文件包含有关崩溃的以下详细信息。

#  SIGSEGV (0xb) at pc=0x065e68f4, pid=20208, tid=570166160
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86)

...

# Problematic frame:
# V  [libjvm.so+0x5e68f4]

...

Current thread (0x099ea800):  JavaThread "Thread-315" daemon [_thread_in_vm, id=25782, stack(0x21fa3000,0x21fc1000)]

...

vm_info: Java HotSpot(TM) Server VM (10.0-b23) for linux-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:20:15 by "java_re" with gcc 3.2.1-7a (J2SE release)

所以这告诉我 JVM 在运行一些 Java 代码时遇到了段错误。错误日志还包含有关崩溃线程堆栈的信息。

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x5e68f4]
V  [libjvm.so+0x1c054f]
V  [libjvm.so+0x1bfef2]
V  [libjvm.so+0x1bf57f]
V  [libjvm.so+0x592495]
V  [libjvm.so+0x365c4e]
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
J  org.myapp.AppClass.getBytes()Lorg/myapp/ByteHolder;

我已经使用 GDB 从崩溃中连接到核心文件并获取有关堆栈的更多详细信息。这给了我以下输出。

#5  <signal handler called>
#6  0x065e68f4 in interpretedVFrame::monitors() const ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#7  0x061c054f in get_or_compute_monitor_info(JavaThread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#8  0x061bfef2 in revoke_bias(oopDesc*, bool, bool, JavaThread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#9  0x061bf57f in BiasedLocking::revoke_and_rebias(Handle, bool, Thread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#10 0x06592495 in ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#11 0x06365c4e in InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so

这表明原始错误报告中列出的六个 libjvm.so 帧与获取 Java 锁有关。但是，我在 org.myapp.AppClass.getBytes() 中找不到任何使用任何锁的代码。

堆栈中的 BufferBlob::Interpreter 行是什么意思？这些是 Java 堆栈帧吗？ JVM堆栈帧？是否可以计算出这些堆栈帧中调用了什么？

注意：请不要建议我尝试切换到更新的 Hotspot JVM。我依赖 CMS 收集器，而最近的 V1.6 Hotspot JVM 都没有一个足够稳定的 CMS 收集器。

编辑：本文档 (http://www.oracle.com/technetwork/java/javase/tsg-vm-149989.pdf) 指出“v”帧是“VM 生成的存根帧”。知道这意味着什么吗？

EDIT2：org.myapp.AppClass.getBytes() 从 DataInputStream 读取。这可能涉及以下堆栈跟踪：

AppClass.getBytes()
AppClass.readByte()
DataInputStream.readByte()
SocketInputStream.read()
SocketInputStream.read(byte[],int,int)
PlainSocketImpl.aquireFD()

最后一个方法获取锁。这可能是最终调用上面列出的 JVM 代码的来源。上面的这个堆栈有一个简洁的特性，即在 getBytes() 下面有 5 个 Java 堆栈帧。这将与“Java 框架”列表中的 5 行 BufferBlob::Interpreter 完美匹配。

这提出了几个新问题：

“Native frames”下的 BufferBlob::Interpreter 的 5 行是否可能 部分只是“Java 框架”部分下相同行的重复项？ 为什么错误日志没有显示这 5 个堆栈帧的详细信息？

EDIT3 - 这个 Oracle 错误看起来可能是相同/相似的错误：http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6676175

显示的堆栈跟踪不完全相同，但它提到了 revoke_and_rebias 中罕见的竞争条件，该条件已在 6u14 中修复。

EDIT4 - 赏金消息应显示“熟悉 Hotspot 实现”

【参考方案1】：

VM generated stub frame只是表示正在执行的代码已经被JVM生成了。

堆栈本身（来自 gdb）显示 VM 正试图到达安全点，因为它正在撤销偏向锁。您可以在this blog 中阅读有关偏向锁定的信息。这意味着某个线程已经获得了一个监视器，该监视器将该监视器偏向该线程。后来其他一些线程想要锁，所以它必须撤销需要到达安全点的偏差（即没有线程正在执行字节码，也就是停止世界）。

您的错误也可能表明 JVM 在取消优化某些方法期间崩溃。这意味着 JVM 已经优化（编译）了某些方法，但随后遇到了导致它需要取消优化的代码路径，因为编译的方法不再有效。如果没有 JVM 升级，您不太可能找到解决此问题的方法。

您似乎有 2 种解决方法可以尝试

如果它由偏向锁定驱动，请将其关闭 (-XX:-UseBiasedLocking) 如果它是由去优化驱动的，找到有问题的方法并告诉hotspot不要首先编译它，关于如何做到这一点的说明this link

这两种方法都可能对性能产生影响。

注意，如果您能制定出可靠地重现问题的测试场景，这将不会那么令人沮丧。

【讨论】：

“表示正在执行的代码已经由 JVM 生成，即编译（优化）代码”——JVM 设法将其命名为“org.myapp.AppClass.getBytes()”，尽管它是编译的方法（根据标签“J”）。 JVM 是否有时无法命名正在执行的方法？还是“BufferBlob::Interpreter”行是指 JVM 插入到我的程序中的一些隐式工作？

我编辑了那一点，因为这不是我想说的。据我所知，一个简单的编译方法仍然显示为 J 。 Interpreter 行确实引用了 JVM 创建的代码。 JVM 会做很多其他事情（GC、优化）来运行您的代码。

嗯，这是有道理的，除了我相当确定我在堆栈中的方法 (org.myapp.AppClass.getBytes()) 没有做任何锁定。这就是为什么我假设 BufferBlob::Interpreter 行必须代表进一步的方法调用。这可能吗？我以为 GC 和 JIT 发生在各自的线程中。

本文提供了一些关于去优化如何实际发生的信息 - cs.princeton.edu/picasso/mats/HotspotOverview.pdf - 以及此处的偏差撤销摘要 - oracle.com/technetwork/java/javase/tech/… - 两者都需要达到安全点，这意味着强制线程停止.我认为解释器的东西是指解释的帧，所以它可能已经从编译的方法切换回了去优化的版本。我倾向于使用-XX:+PrintCompilation 来更详细地了解正在发生的事情。

【参考方案2】：

Tom Rodriguez 现在已经在热点运行时开发邮件列表中回答了这个问题。

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-November/002592.html