incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: JavaStackFrame/JavaLocation local variable support
Date Wed, 01 Jul 2009 12:03:51 GMT
Thanks Konstantin, I had you in mind when I brought this up :-)

The local variable support is another case of deciding on what "model" 
of the JVM we will present - balancing between implementation
details and presenting a consistent API that can have the same Java 
program introspected in the same by the same analyzing program (JDI,
FFDC, etc) but on different JVMs.

I think that local variables will be an optional feature of the API. I 
do wonder if it will be possible to set a minimum level of
expected support. For instance, can the "this" variable (where present) 
and the arguments to the method be set as a minimum requirement?

We want to be able to bring these issues to a conclusion. The RI is 
important - Steve has been working on getting a JVMTI agent that will
produce the local variables. What I'm not quite sure on is how we decide 
upon the optionality of such features. For instance, some JVMs
might never support local variables, while other might just support them 
in intepreted frames. In addition, the different implementations of
Kato will determine the amount and  information generated. For instance, 
a core file with jsadebugd (or something much like it)
could have another set of features compared to the JVMTI agent.

With local variable support as an example, as well as assessing what is 
practicable for the RI should we be investigating the capabilities of 
the JVMs
that would be retrieving local variables to determine the optionality? 
For that I mean IBM, Oracle and Sun's JVMs and their possible Kato 
as well as the RI.


Bobrovsky, Konstantin S wrote:
>> we know that they were in a -> b -> c somewhere, but we wouldn't know 
>> whether they were still in d or e.  Is that right?
> Sorry, I don't quite understand the question. What is the sense of 'they' and 'were'
you implied here?
> Thanks,
> Konst
> Intel Novosibirsk
> Closed Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park, 
> 17 Krylatskaya Str., Bldg 4, Moscow 121614, 
> Russian Federation
> -----Original Message-----
> From: Nicholas.Sterling@Sun.COM [mailto:Nicholas.Sterling@Sun.COM] 
> Sent: Wednesday, July 01, 2009 5:15 PM
> To:
> Subject: Re: JavaStackFrame/JavaLocation local variable support
> Bobrovsky, Konstantin S wrote:
>> Hi Nicholas,
>> C2 compiler annotates each safepoint with so-called DebugInfo (serialized together
with method's executable image), which records an entire in-lining hierarchy for this particular
> Ah, I'm with you now -- thanks!  :^)  You're right, something like this 
> is needed for de-optimization.
> So in general we would be between safepoints, and most call sites are 
> safepoints.  If the first safepoint has backtrace
> a -> b -> c -> d -> e
> and the second has
> a -> b -> c -> g -> h -> i
> we know that they were in a -> b -> c somewhere, but we wouldn't know 
> whether they were still in d or e.  Is that right?
> Nicholas

Stuart Monteith

View raw message