incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject JavaStackFrame/JavaLocation local variable support
Date Wed, 13 May 2009 12:48:34 GMT
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();
}

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.

Thoughts?
    Stuart


Mime
View raw message