incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject Re: JavaStackFrame/JavaLocation local variable support
Date Wed, 13 May 2009 13:22:39 GMT
On Wed, May 13, 2009 at 1:48 PM, Stuart Monteith <> wrote:

> Hello,
>   With Steve's work on JVMTI/python coming along, the issue of what to do
> about local methods is coming up. Currently there is no means to determine
> the names and values of local variables through the current API.
> The most obvious way of implementing this is to have the API do all of the
> processing by exposing the variables as name and value pairs.
> For example:
> interface JavaStackFrame {
>   List<LocalVariable> getLocalVariables();
> }
> where:
> interface LocalVariable {
>   String getName();
>   Object getValue();
> }

I like this but wonder if it is sufficient -  What about slot numbers?

> Where the value is a JavaObject, or an boxed primitive.
> The other extreme is for the necessary information to be made available for
> the callers of the API to generate this information themselves.
> This would mean properly exposing:
>   Program Counter - currently we have JavaLocation.getAddress(), which is
> an address in memory, rather than a bytecode program counter. For JITted
> frames we'd still need the bytecode program counter.
>   Local variable table - this is to determine which variables there are,
> their types and their indexes into the local variable array
>   Local variable array - the contents of the local variables need to be
> exposed, and their proper types should be returnable (JavaObject, int, etc).
> Doing it that way might be beneficial for more user stories, there is more
> information available to reconstruct the class file, for instance.
> There is also the small matter of what to do when the local variable table
> is not available. When the API exposes all that it knows the values might
> still be retrievable, although I have my doubts as to how useful that would
> be if you don't know the types.

Agree with all of this -  I think we should do an experimental
implementation based on your proposal above (as it provides the least that
will be needed) and see how it works in practise.

> Thoughts?
>   Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message