incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Pilkington" <>
Subject Runtime and Process Explorers
Date Wed, 14 Jan 2009 17:11:56 GMT
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.

>From an API perspective I think that these tools will expect the following
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 ?


Adam Pilkington

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