将 BCI（字节码索引）转换为源代码行号
我正在编写 JVMTI 代码来分析 Java 程序，这主要需要使用函数 AsyncGetCallTrace 以固定的时间间隔从随机线程获取堆栈跟踪。因此，我能够获得 CallTrace 结构，每个结构都包含一个 CallFrame 结构数组，其中包含有关堆栈跟踪中各个帧的数据。具体来说，这些数据包括：jmethodID method_id（框架所在的java方法的ID），和：jint lineno（.class文件中该方法的BCI，据我理解的文档）。我似乎找不到使用 JVMTI 框架将这个“lineno”转换为相应源代码行号的方法（至少参见文件 jvmti.h，位于 /usr/lib/jvm/java-6-sun/include 中）在 Linux 上）。事实上，即使在 JVMTI 框架之外，到目前为止我在网上能找到的唯一东西就是这里： http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/classfile/LineNumberTable.html，但即使这样也可能不会做我的事情想要，并且需要额外的安装，并且要求我使用单独的 Java 程序处理由 C++ JMVTI 代码生成的数据。
如果有人知道如何从 JVMTI 内（或什至以任何方式）将 BCI 转换为源代码行号，请帮忙！
[如果有人很了解这个领域，请告诉我，因为我还有一些关于这个过程的问题要问。]
I am writing JVMTI code to profile Java programs, which mostly entails obtaining stack traces from random threads at fixed time intervals using the function AsyncGetCallTrace. Thus, I am able to obtain CallTrace structures, each of which contains an array of CallFrame structures, which contain data about individual frames in a stack trace. Specifically, these data consist of: jmethodID method_id (the ID of the java method where the frame is located), and: jint lineno (the BCI of the method in the .class file, as far as I understand the documentation). I cannot seem to find a way to convert this "lineno" into the corresponding source code line number using the JVMTI framework (see file jvmti.h, located in /usr/lib/jvm/java-6-sun/include, at least on Linux). In fact, even outside the JVMTI framework, the only thing I could find on the web so far was here: http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/classfile/LineNumberTable.html, but even this may not be doing what I would like, and requires additional installation, AND requires me to process the data, which was generated by C++ JMVTI code, using a separate Java program.
If anyone knows how to convert BCI to source code line numbers from within JVMTI (or even in any way), please help!
[If someone knows this field well, please let me know, since I have a few more questions to ask about the process.]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想我已经明白了这一点。主要使用的方法是jvmti->GetLineNumberTable(...)，它填充一个jvmtiLineNumberEntry数组。给定 BCI 行号 n（将映射到源行号），可以测试 int i 是哪个： jvmtiLineNumberEntryArray[i] <= n < jvmtiLineNumberEntryArray[i + 1]。这个 int i 就是所需的相应源代码行号。
一个问题是，由于某种原因，AsyncGetCallTrace 始终返回奇怪的 BCI，因此尽管映射给出了精确源代码行号，但它们仍然不准确，因为原始的 BCI不准确。这是为什么，我不知道。我希望使用 Sun Studio 分析器（它也使用 AsyncGetCallTrace）来测试返回的行号是否与我的分析器的行号相同。在这种情况下，AsyncGetCallTrace 函数不准确。但到目前为止，使用 Sun Studio 本身就成了一个挑战。 如果有人知道如何使用此工具，请帮忙！
一个更大的问题是 Java 方法通常是内联的，因此行号并不总是正确映射。事实上，这可能是上面段落中描述的问题的原因，尽管根据我所看到的数字，这似乎不太可能。以下是有关解决内联问题的一些信息： http://developer.amd.com /documentation/articles/pages/JVMTIEventPiggybacking.aspx
I guess I somewhat figured this out. The main method to use is jvmti->GetLineNumberTable(...), which fills up a jvmtiLineNumberEntry array. Given the BCI line number n (which is to be mapped to a source line number), one can test for which int i is: jvmtiLineNumberEntryArray[i] <= n < jvmtiLineNumberEntryArray[i + 1]. This int i is then the desired corresponding source code line number.
One catch is that AsyncGetCallTrace, for some reason, consistently returns weird BCIs, so although the mapping gives precise source code line numbers, they are still not accurate, because the original BCIs are not accurate. Why this is, I do not know. I was hoping to use the Sun Studio profiler, which also uses AsyncGetCallTrace, to test whether the returned line numbers would be the same as they are for my profiler. In that case, the AsyncGetCallTrace function is inaccurate. But so far, using the Sun Studio turned into a challenge of its own. IF ANYONE KNOWS HOW TO USE THIS TOOL, PLEASE HELP!
A bigger catch is that Java methods are often inlined, so line numbers do not always map correctly. In fact, this MIGHT be the cause of the problem described in the paragraph above, although this seems unlikely based on the numbers I've been seeing. Here is some information about solving the inlining problem: http://developer.amd.com/documentation/articles/pages/JVMTIEventPiggybacking.aspx