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.


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.


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 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.


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.