incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sonal Goyal <>
Subject Re: Runtime and Process Explorers
Date Mon, 19 Jan 2009 09:41:35 GMT
Hi Adam,
Thanks for your email and the detailed explanation of the tool. I have the
following suggestions:

1. It may be useful to be able to link to source code.
2. I think if we could include an overview or summary section in the tool,
it will enhance the usability.

Thanks and Regards,

On Wed, Jan 14, 2009 at 10:41 PM, Adam Pilkington <> wrote:

> Hi all, my name is Adam Pilkington and I'm a member of Steve's team. I'm
> using this post to start a thread for discussing how the explorer tools
> (that's the Process and Runtime Explorers) should be developed.
> I think that the use cases are going to be very much along the lines
> outlined by Steve in his original post, particularly as we have identified
> the Runtime Investigator as a separate tool.
> *Use Cases*
> 1) Dump exploration : given a particular dump file, then you want to wander
> through all the available data seeing what is there.
> 2) Data verification : given a particular dump file, then you wish to
> verify
> the contents of the dump match your expectations. A simple example of this
> would be to check the presence of a certain object instance on the heap,
> and
> possibly that the field values were correct.
> *Characteristics*
> From an API perspective I think that these tools will expect the following
> characteristics
> 1)  Lightweight - only deal with what is being requested by the user. This
> should ensure a fast startup and subsequent navigation.
> 2) Random access of the dump file (if possible we want to avoid
> sequentially
> iterating over data items). This will also cover the aspects of dealing
> with
> large quantities of data.
> *Functional Requirements
> *The following is an initial list of common tools functionality which will
> be required to support the use cases.
> 1) Data type specification : the ability to tell the UI to display the data
> at a given address as a specific data type e.g. this address represents the
> start of a null terminated string.
> 2) Data overlays : the ability to override the actual byte values contained
> in a dump with user defined values and have the UI work with the updated
> value. This means that you would be able to potentially fix corrupt
> structures or lists by specifying the correct values. You should then be
> able to save and reload these overlays as required.
> 3) Automatic determination of dump type
> 4) The ability to launch other tools, such as the Runtime Investigator,
> from
> the explorer. This can be simply launching the tool or launching with a set
> of command line options which make sense within the current explorer
> context.e.g. the explorer shows a large heap occupancy, so you launch the
> Runtime Investigator which starts a heap occupancy analysis.
> Ultimately these tools are going to be driven by the user interface.
> Initially we may aim to present this as a standard two pane, tree view type
> explorer, however as we come to use this ourselves and find that the UI is
> lacking, then further requirements may come to light.
> Are there any thoughts on other UI paradigms or use cases that we may wish
> to support in the explorer tools ?
> Regards
> Adam Pilkington

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