incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sonal Goyal" <sonalgoy...@gmail.com>
Subject Re: Tool Prioritisation
Date Mon, 12 Jan 2009 06:16:11 GMT
Hi All,
My preferences are:

(1)  3: Java Runtime Explorer
(2)  8 : Retrospector
(3)  5: Java Runtime Trend Analyzer
(4)  2: Native Memory Analyser Tool

To me, the JDI connector and MAT adapters are important in terms
of compatibility and wider adoption, but they do not necessarily provide
extra information to the developer. The Native Memory analyser tool - I feel
it is one of the examples cited in the JSR, and we should at least chalk out
how much of it is feasible and what it takes.

Thanks and Regards,
Sonal


On Thu, Jan 8, 2009 at 9:05 PM, Bobrovsky, Konstantin S <
konstantin.s.bobrovsky@intel.com> wrote:

> Hi Steve, all,
>
> My preferences:
>
> (1) 3: Java Runtime Explorer
> (2) 6: Java Debug Interface (JDI) Connector
>
> These two seem a must-have to me. That's what core file + gdb (or minidump
> + VC debugger) are about on the native side, and this is a primary
> functionality used first when solving problems and which is missing in the
> Java space. JDI connector is an important usability improvement factor that
> will allow quicker adoption of the concept.
>
> (3) 5: Java Runtime Trend Analyzer
>
> This is an important piece of the infrastructure (if I understood what it
> does correctly), and should be part of the proof-of-concept.
>
> (4) 8 : Retrospector
>
> That (well, something like) is what I (and few people I know) dreamed of
> when debugging Hotspot crashes on 8-core Itanium with its extreme memory
> model :-)
>
> At this point I don't see any technical feasibility issues with
> implementing these 4.
>
> The other 4 tools seem very useful too, but they are IMO either less
> general and have lesser target audience (native memory analyzer) or have
> some existing analogs which can do the part of the job.
>
> Thanks,
> Konst
>
> P.S. I'm on vacations till Jan 26 with casual access to e-mail.
>
> 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: Thursday, January 08, 2009 8:12 PM
> To: kato-spec@incubator.apache.org
> Subject: Tool Prioritisation
>
> Greetings.
>
> We haven't quite closed on the list of example tools but I think its
> important that we start to prioritise the list we have already.  I'd like
> to
> spend the rest of the month expanding the requirements we have for our top
> 3
> or 4  tools.   I would ask you all to respond with your view on the
> prioritisation of the list below.   Highest being most important.
> Additionally , if you have an opinion, please indicate as a comment if the
> tool seem to be relying on  a technical aspect  that is not feasible to
> implement.  (For instance the Native Memory Analysis Tool proposal assumes
> that getting access to memory allocation info from a dump is practicable -
> we have some work to do to figure out what is really achieveable)
>
> If the quick definition for a tool is unclear dont feel shy about asking
> for
> clarity - or even proposing your own.
>
>
> [ps I've left off Konst's  "debugger with memory" idea as it needs more
> work
> to explain what the tool would do and look like]
>
>
> The list:
>
> Sample Tools - the primary drivers for developing  JSR User Stories
>
>
> 1: Process Explorer
>
> An Eclipse plugin which allows presentation, navigation and simple querying
> of the elements of a Process Dump.   This tool will demonstrate how to
> explore a dump in an efficient and high performing manner.   Key
> characteristics will include  fast startup time, handling of large
> quantities of data (including summarization), effective navigation to areas
> of interest.
>
>
> 2: Native Memory Analyser Tool
>
> A program that can retrieve native memory allocations by (or on behalf of)
> a
> Java Runtime and provide trace back to the  Java objects that hold the
> allocation reference.   The tool will be able to display what memory
> allocations exist, the contents of the allocation, and conservatively
> identify which entities hold references to that allocation.  Ideally this
> tool will be able to point to specific fields within Java objects that hold
> the references.   This tool will demonstrate the capabilities   of the API
> to find and display native memory  from a memory manager.    Key
> characteristics will include the performance of the API in  exhaustively
> scanning a dump (for memory allocation handles) and the ability to resolve
> an arbitrary location within the dump into a Java object or similar entity
>
>
> 3: Java Runtime Explorer
>
> Similar to the Process Explorer above this Eclipse plugin will allow the
> presentation, navigation and  simple querying of the elements of a Java
> Runtime dump. This tool will demonstrate how to explore a Java runtime dump
> in an efficient and high performing manner.   Ideally the plugin will also
> demonstrate the APIs ability to  provide some support for  virtualisation
> of
> Java runtime objects so that implementation specifics concerning objects
> within  the java.lang and java.util packages can be hidden.   Key
> characteristics will include  fast startup time, handling of large
> quantities of data (including summarization), effective navigation to areas
> of interest, useful abstraction of key Java object implementation specifics
>
>
> 4:  Runtime Investigator
>
> 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.
>
>
> 5: Java Runtime Trend Analyzer
>
> A tool that can compare multiple dumps and provide trend analysis.  This
> tool will provide analysis modules that can report on such items as  heap
> growth etc The tool will provide extension points that will allow others to
> contribute new analysis modules.  Key characteristics of this tool will
> include exercising  the creation of well formed dumps,  fast startup time,
> correlation between dump objects and 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.
>
>
> 6: Java Debug Interface (JDI) Connector
>
> An adapter that allows a Java debugger to interrogate the contents of a
> Java
> Runtime diagnostic artifact.  This connector will enable similar
> capabilities that exist today with other debuggers than can debug corefiles
> or similar process diagnostic artifacts.   This tool will demonstrate  key
> characteristics such as effective navigation to areas of interest, useful
> abstraction of key Java object implementation specifics and that the API
> provides  the data that required to analyze real problems.
>
>
> 7: Memory Analyser Tool (MAT) Adapter
>
> MAT (http://www.eclipse.org/mat/) is an open source project that consumes
> HPROF and DTFJ supported dumps.  MAT is designed to help find memory leaks
> and reduce memory consumption.  An adapter for MAT will be developed that
> allows MAT to consume HPROF and other dumps via the JSR 326 API.   Key
> characteristics of this adapter will include  handling large quantities of
> data efficiently,  useful abstraction of key Java object implementation
> specifics and  dump type identification.
>
>
> 8 : Retrospector
>
> One of the rationales behind the JSR-326 was complexity of failure &
> performance analysis increasing with CPU core count growth.  This tool will
> showcase this rationale. The tool will present a number of landmarks or
> checkpoints in the code and display  how their mutual temporal ordering and
> latency change (a) over time (b) depending on the number of threads (c)
> depending on the number of available CPU cores etc
>
> Checkpoints can be of different kinds:
>            - well-known events defined by JVMTI (monitor enter/exits,
> method entry/exits, class loads, code generation, thread lifecycle
> events,...)
>           - new kinds of events helping solve particular problems. For
> example, interpreted -> compiled code execution mode change for a method,
> reaching a safepoint (in Hotspot terms), native memory allocation in from
> JNI code, arbitrary checkpoint specified by a user as <method, bytecode
> position> pair (with optional additional refinements or filtering), etc.
>
> This tool will likely require additions within the JRE such that   when a
> checkpoint is reached by a thread, the JRE internally quickly logs this
> fact
> by adding a record <checkpoint ID, thread ID, timestamp, pc, ...> into a
> buffer, which, at appropriate time, is processed and made available via the
> JSR-326 API. [Note: The logging should be extremely efficient to minimize
> the "observer effect", which seems quite possible with thread-local
> checkpoint event buffer.].
>       The retrospector tool will be able to load the 2 or more checkpoint
> logs and
>       - split up each of them into per-thread events
>       - visualize the checkpoint events mapped onto the timescale
>       - visualize the difference in temporal behavior between two threads
> within the same run of the analyzed app, between two threads within
> different runs on the analyzed app
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message