Re: RFA: JVMTI GetFrameCount

[Kyle Galloway <kgallowa at redhat dot com>]

Tom Tromey wrote:
> > > > > > "Kyle" == Kyle Galloway <kgallowa@redhat.com> writes:
> > > > > >             
>
> Kyle> This patch implements the GetFrameCount functionality of jvmti.  Any 
> Kyle> comments? If not could someone please commit this.
>
> I have a couple questions about it.
>
> Kyle> +  //get the top frame
> Kyle> +  _Jv_InterpFrame* top = reinterpret_cast<_Jv_InterpFrame *> (t->interp_frame);
> Kyle> +  *count = 0;
>
> First, there seems to be a race condition here, if the request is for
> a thread other than the current thread.  In this case the data we're
> accessing might be invalidated while we're running, leading to crashes
> or other weirdness.
>   
This implies that we need to suspend the thread, at least temporarily, 
to keep the interpreter from crashing.  The problem being that JVMTI 
doesn't use a suspend count for each thread.  The result of this is that 
if we use this method to implement a JDWP call (which does use a suspend 
count) there is no way to make sure the thread isn't resumed out from 
under JDWP since the JVMTI resume call resumes the thread regardless of 
the suspend count.  The solution is probably to have JVMTI use a suspend 
count internally so it can keep in sync with JDWP.
> Second, while I understand that we're likely only to be able to debug
> interpreted frames, in a case like this we may want to consider
> getting a full stack trace, rather than simply pulling out the
> interpreted frames.  I'm not really sure however.
>   
This is more a problem with the structure of the stack from within the 
interpreter.  The structure that the thread is aware of is a linked list 
containing only the interpreted stack frames.  The easiest way to fix 
this would simply be to create a superclass to hold either the current 
_Jv_InterpFrame structure or a placeholder for a native call so that the 
JVMTI functions will be aware of it.  Is there another way to do this?

Kyle