You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Steve Poole <sp...@googlemail.com> on 2009/03/24 09:35:10 UTC
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
RE: Runtime Investigator usecases
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
> 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
>
Re: Runtime Investigator usecases
Posted by Steve Poole <sp...@googlemail.com>.
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
>
RE: Runtime Investigator usecases
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
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:
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.)
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