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: Runtime Investigator usecases
Date Wed, 25 Mar 2009 04:38:45 GMT
> This is an especially interesting  idea to raise.  Its something that I've
> discussed inside IBM as well.  You can see the benefit to a JVM/JIT
> developer in exposing this data but its not going to be useful to an
> application developer unless it can be generalised -  I don't have any
> specifics just making the observation.Since generlisation isn't useful for
> a jit developer etc I assume that what we need to provide is both a
> generalised view and the ability for a specific jvm/jit vendor to enhance
> the view with its own specifics.

Yes, this makes sense. Then Kato API could probably provide some plug-in mechanism for 3-rd
party code which can interpret/visualize such JVM-specific data associated with method (or
more generally, with any piece of general data at any level of its hierarchy).

A particular example of general JVM data associated with the method could be the GC map (as
probably all major JVMs have some kind of GC maps for compiled methods), VM-specific (Hotspot-specific)
data example are DebugInfo (among other things keeps map of where JVM state constituents reside
at a particular IP) or ImplicitNull table which records IPs where "legal" null-dereference
can occur.

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: Steve Poole [mailto:spoole167@googlemail.com] 
Sent: Wednesday, March 25, 2009 4:11 AM
To: kato-spec@incubator.apache.org
Subject: Re: Runtime Investigator usecases

On Tue, Mar 24, 2009 at 12:39 PM, Bobrovsky, Konstantin S <
konstantin.s.bobrovsky@intel.com> wrote:

> Hi Steve, all,
>
> To me, all the scenarios you listed are relevant to the tool.
>
> Not sure if you meant this list for extension, but in case you did, here
> are several additions which imply necessity in particular kinds of
> information:
>

I sure did :-)

>
> RXX:  As a programmer diagnosing application failure, I want to see
> (address ranges of) all memory pages allocated (reserved or committed) by
> the application along with their attributes, so that I could understand
> memory page characteristics a particular code/data address belongs to.
>

> RXX: (exists in Hotspot crash dump) As a programmer diagnosing application
> failure, I want to see mapping of modules loaded by the application to
> virtual address so that I could identify which module a particular
> code/static data address belongs to.
>
> RXX:  As a programmer diagnosing application failure, I want to have
> bytecodes of all the Java methods whose activations are seen on the stack of
> the thread where failure in the Java code occurred. For each method in the
> stack I also want to have full JVM state (pc, values of locals, expression
> stack depth and contents, acquired Java-level monitors). This would help me
> in failure analysis and allow me to craft a simpler reproducer of the
> problem.
>
> RXX: As a programmer diagnosing application failure, I want to see the
> native code of the compiled method where the crash occurred and all internal
> JVM data structures associated with the method (GC maps, etc.)
>

This is an especially interesting  idea to raise.  Its something that I've
discussed inside IBM as well.  You can see the benefit to a JVM/JIT
developer in exposing this data but its not going to be useful to an
application developer unless it can be generalised -  I don't have any
specifics just making the observation.  Since generlisation isn't useful for
a jit developer etc I assume that what we need to provide is both a
generalised view and the ability for a specific jvm/jit vendor to enhance
the view with its own specifics.

>
> RXX: As a programmer diagnosing JVM crash, I want to see JVM-specific
> attributes of each thread, such as thread state ("in java", "in jvm", ...),
> list of local JNI handles, to better understand internal state at the moment
> of failure.
>
> 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: Steve Poole [mailto:spoole167@googlemail.com]
> Sent: Tuesday, March 24, 2009 3:35 PM
> To: kato-spec@incubator.apache.org
> Subject: Runtime Investigator usecases
>
> Hi All -  I've been thinking about the usecases we could image for
> investigating the contents of diagnostic artifact.   I initially described
> the tool as
>
> "A program that can examine a dump and provide guidance on common aliments.
> This tool will provide analysis modules that can report on such items as
> deadlock analysis,  heap occupancy etc The tool will provide extension
> points that will allow others to contribute new analysis modules.  Key
> characteristics of this tool will include handling large quantities of data
> efficiently  (probably via a query language of some type) , ensuring the
> API
> is generally consumable by programmers and ensuring the API provides the
> data that is actually required to analyze real problems."
>
>
> This tool is probably one of the most important and all encompassing we
> have. so the user story list for this tool could be quite large.  Rather
> than attempt to list everything I'm going to list some examples and see
> what
> you all think.
>
>
> RI1: As a programmer diagnosing an application failure,  I want to see  the
> threads that were active when the dump was created including the java stack
> and native stack so I can see where my application was when it terminated
>
> RI2: As a programmer diagnosing an application failure,  I want to see  any
> native library code and what entry points in the library are active on the
> thread stacks so I can see where my application was when it terminated
>
> RI3: As a programmer diagnosing an application hang or deadlock, I want to
> see  what monitors are held and or waited for by the various threads so I
> can see what my application  was doing at the time.
>
> RI4: As a programmer diagnosing an application hang or deadlock I want to a
> report of any deadlock situations including a list of threads, monitors and
> associated java code involved, so I can see what my application  was doing
> at the time.
>
> RI5: As a programmer diagnosing an application hang I want to see what
> threads are waiting for a response from an external process,so I can see
> what my application  was doing at the time.
>
> RI6: As a programmer diagnosing an application failure, I want a report of
> jvm launch information including command line , environmental variables etc
> , so that I can check that my starting assumptions are correct
>
> RI7: As a support engineer receiving the diagnostic artifact I want to know
> what was the  the initiating cause of the dump - ie out of memory, process
> failure,  snapshot triggered
>
> RI8:  As a programmer diagnosing an out of memory situation , I want a
> summary report of the heap which  lists number of objects generally and
> specifically - ie bytebuffers . classloaders. so that I can understand the
> characteristics of the problem
>
> RI9:  As a programmer diagnosing an out of memory situation , I want a
> summary report of root objects that retain large amounts of heap, so that I
> can identify potential culprits.
>
> RI0:  As a programmer diagnosing an out of resource situation ,I want a
> report of open sockets and paths to them from thread roots
>
>
> Steve
>

Mime
View raw message