incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bobrovsky, Konstantin S" <konstantin.s.bobrov...@intel.com>
Subject RE: JavaStackFrame/JavaLocation local variable support
Date Thu, 02 Jul 2009 05:28:58 GMT
>> For instance, can the "this" variable (where present) 
>> and the arguments to the method be set as a minimum requirement?

> I don't think it is always possible, even in Hotspot VM.

To put it simpler, there is a chance for us to get values of arguments at any point in the
code only if the arguments are 'live' at this point - this seems far too strong requirement.
'This' is probably different - javac might keep it intact at the top of the virtual stack
until the end of the method, i.e. it is always 'live'.

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: Bobrovsky, Konstantin S [mailto:konstantin.s.bobrovsky@intel.com] 
Sent: Thursday, July 02, 2009 12:18 PM
To: kato-spec@incubator.apache.org
Subject: RE: JavaStackFrame/JavaLocation local variable support


Stuart, all,

Few comments from my side:

> For instance, can the "this" variable (where present) 
> and the arguments to the method be set as a minimum requirement?

I don't think it is always possible, even in Hotspot VM. According to the JVM spec 'this'
and arguments are passed via virtual stack, and the stack slots they occupy can be overwritten
by some bytecode executed between the method entry and the point where we query their values.
So Hotspot's keeping VM state maps does not help.

On a native level, we need to know calling convention for java methods of each VM, particularly,
where arguments are stored (regs or stack) and whether their values are preserved by the callee
(extremely unlikely). If we are lucky, we can find a VM for which we can deduce location of
arguments at any particular point in method's code. Hotspot (C2) is probably not one of them.

> If a tool operates against a live JVM, it should probably not affect the
> target Java application's
...
> For instance, some JVMs
> might never support local variables, while other might just support them 
> in intepreted frames.

This is important point, IMO. Support for certain features might require live VM to 'deoptimize'
certain compiled methods (local variables access is a good example, another one is a breakpoint
hit) - do we allow that in the spec or do we at all specify implementation behavior in this
case? For debuggers changing optimization level or otherwise affecting execution (preserving
only semantics) is justifiable, but for the purposes the Kato is for - probably not, I agree
with Stuart.

> 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?

IMO, it would be very useful. A VM/feature table for the major VMs out there and for all important
features which impact API design (safeponits + deoptimization/on-stack replacement, recompilation,
compressed pointers, ...) would help see the whole picture and judge whether a support for
a particular feature on the API level is worthwhile or it should be left to custom VM-specific
tools only. If we ever decide to do that - I could help with populating Hotspot VM part.

One obvious suggestion: API could allow query of capabilities from the host VM or the loaded
org.apache.kato.image.Image so that tools could partially handle optionality of certain features
at run-time. This way the same tool can be more 'smart' on a VM with extended capabilities.
Similarly to capabilities mechanism in JVMTI.

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: Stuart Monteith [mailto:stukato@stoo.me.uk] 
Sent: Wednesday, July 01, 2009 7:04 PM
To: kato-spec@incubator.apache.org
Subject: Re: JavaStackFrame/JavaLocation local variable support

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 
implementations
as well as the RI.


Regards,
    Stuart

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: kato-spec@incubator.apache.org
> 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
safepoint, 
>>     
>
> 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
http://blog.stoo.me.uk/


Mime
View raw message