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 Tue, 24 Mar 2009 12:39:40 GMT
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

Mime
View raw message