This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] JVMTI Stack Tracing


Andrew Haley wrote:
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.


I'm baffled.  We already have a good way to generate stacktraces.  Why
can't you do something like this?

_Jv_StackTrace *st = _Jv_StackTrace::GetStackTrace ();

// If start_depth is negative use this to determine at what depth to start
// the trace by adding it to the length of the call stack. This allows the
// use of the same frame "discarding" mechanism as for a positive start_depth
if (start_depth < 0)
start_depth = *frame_count + start_depth;
// Now check to see if the array supplied by the agent is large enough to
// hold frame_count frames, after adjustment for start_depth.
if ((*frame_count) > max_frames)
(*frame_count) = max_frames;
for (int i = start_depth; i < (*frame_count); i++)
{
_Jv_StackTrace::FillInFrameInfo (st[i]);
frames[i].method = st[i]->meth;
// Set the location in the frame, native frames have location = -1
if (st[i]->type == frame_interpreter)
{
_Jv_InterpMethod *imeth = static_cast<_Jv_InterpMethod *> (frame->interp->meth);
The problem with this method is that, to my knowledge, this gets a trace from the context in which it is called. So if I call if from a JVMTI method, it will trace the path that led to the JVMTI call, which in our case will likely be from JDWP. The thread parameter passed to GetStackTrace indicates the thread that should be traced, and from what I have seen (and I admit, I'm fairly new at this) there is no way to use the existing stack tracing mechanism to get a trace of an arbitrary thread. In case this is not clear, I'll give an example:

I write a Java program with three threads (say threads A, B and C), and I want to debug it using Eclipse (or a similar java debugger that uses JDWP). When I ask for a stack trace of thread A, JDWP will process the packet, then call GetStackTrace from JVMTI with thread A as the first parameter. Using the method you propose, the stack trace would look something like this:

1 : _Jv_JVMTI_GetStackTrace
2: VMVirtualMachine::getFrames
........
........

But it should really look like:

1: A::do_something
2: A::call_do_something
3: A::run
........
........

I should then be able to call it with Thread B or Thread C as a parameter and get their stack trace.

If there is a way to do what I need in the current system, I would be overjoyed to hear about it, but early in the process it was given the impression that this was not possible.

Thanks,
Kyle


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]