Basic Concepts
This section briefly introduces some of the key concepts of TuningFork.
More details on each topic can be found in subsequent sections of the
Reference Manual.
Feeds
Each open trace source in TuningFork is called a feed.
A feed contains feed meta-data and an interleaving of meta-data and data
from one or more feedlets.
If multiple feeds that overlap in time are
opened, it is possible to perform time correlation analysis. Feeds may be either off-line
(read in from a trace file) or on-line (connected over a socket to a running program).
Feed Groups
Multiple feeds can be opened at the same time; each open feed is placed in a feed group.
By default, when a new feed is opened, TuningFork checks to see if the newly opened feed
overlaps in time with any other open feeds. If it does, it is placed in their feed group.
If it does not overlap with any open feed, a new feed group is created to contain it.
A separate Feed Group Explorer is created for each Feed Group.
The Feed Group Explorer is the primary interface for defining new streams and opening figures.
When you select or multi-select nodes of the Feed Group Explorer, right-clicking pops up a menu
of operations that are supported for the selection. Options include defining new Streams and
viewing the Streams in a Figure. Double-clicking on a node performs the default action
for that node. One or more Streams may be dragged and dropped into open Figures
to cause them to be added to the visualization.
Feedlets
Each Feed contains one or more Feedlets.
A feedlet is a logical event-generating entity in the application being traced.
Feedlets also act as units of concurrency and must have the property that all
Events within a single Feedlet are totally ordered in the Feed.
One natural use of Feedlets is for each thread in the instrumented program
to correspond to a Feedlet in the resulting Feed (this is the mapping used by
the WebSphere Real Time and Java Trace Generation Library).
Another natural mapping would be to represent each CPU in an SMP system as a Feedlet.
Events carry the actual data generated by the Feedlets. Each event has a timestamp,
an event type id, and zero or more data fields. Events are variable sized, and the data
portion of each event may carry an arbitrary number of int, long, double, or String
values. The event type is used to parse the events and associate logical names
(defined by the Feed meta-data) with each data value of the Event.
Streams
Streams are the fundamental computational abstraction in TuningFork.
Streams are either base streams that are defined by applying a
filter over the Events in the Feed or derived streams that are defined by
applying an operator to one or more input Streams. There are several types of
streams, the most commonly used are Sample Streams (
),
which represent a series of <time,value>
pairs and TimeIntervalStreams (
),
which represent a series of (possibly overlapping) intervals of time.
Figures
At the heart of TuningFork are the visualization components, called figures.
Figures are responsible for taking one or more Streams and displaying them to the
user. The figure architecture has been carefully designed for extensibility,
device independent rendering, and high performance to allow the display of
live data feeds with high data rates.
Event Type Space
One of the pieces of a Feed's meta-data is the Event Type Space
to which it belongs. For example, all Feeds generated by our SystemTap instrumentation belong
to the SystemTap Event Type Space.
The Event Type Space information is used to associate additional plugins
(for example specialized visualizations and predefined figures) that
apply to the Feed being opened. Event Type Spaces are the primary mechanism used
by TuningFork to communicate domain-specific knowledge of how to analyze or visualize
particular kinds of Feeds to the TuningFork platform.