Re: [RFA] JVMTI Stack Tracing

[Andrew Haley <aph at redhat dot com>]

Kyle Galloway writes:
 > This patch implments the JVMTI methods GetStackTrace and GetFrameCount. 
 >   It is fairly complicated, so it warrants some explanation.
 > 
 > This method of tracing the java stack relies on a frame list that is 
 > created as methods are called.  Is extends the interpreted frame list 
 > already used, and creates a composite stack of all interpreted and JNI 
 > methods in the stack.  To get a stack trace, JVMTI runs through this 
 > composite stack counting up the frames and extracting their info. 
 > _Jv_NativeFrame class is mostly empty, but could be expanded to contain 
 > more information if desired.  I have also maintained compatability with 
 > the current exception stack tracing mechanism by leaving the purely 
 > interpreted list intact.  I added a second variable to Thread.java 
 > called frame (as opposed to interp_frame) which is the first frame in 
 > the composite list.
 > 
 > This method, however, has some limitations, most notably CNI.  Since CNI 
 > is not called through the VM in the way that JNI is, CNI methods will 
 > not show up in this stack trace.  As I understand it, however, this is 
 > not a problem since CNI cannot be used when running interpreted, but I 
 > may be wrong on this point.
 > 
 > I have included a test case for the jvmti-interp.exp file I added 
 > yesterday, which shows GetStackTrace in action.
 > 
 > What does everyone think?  I am very open to suggestions, but given the 
 > nature of CNI and our current goals of interpreted only debugging this 
 > seems like a reasonable solution.

OK, I'm going to think about this for a little while.

Andrew.