Converting BCI (bytecode indices) to source code line numbers

Question

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.]

Shirtmaker

Answer 1

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

Shirtmaker