TuningFork is a system for the visualization, analysis, and control of real-time systems.
TuningFork is built upon the Eclipse Rich Client Platform and itself exports a completely modularized plug-in architecture. New trace formats, analysis modules, and visualizations can all be added as plug-ins.
The J9/Metronome virtual machine has been instrumented with a low-overhead, high-precision trace facility that is capable of emitting cycle-accurate trace events to a socket or a file. Users can also define their own trace events and add records to the trace stream. TuningFork trace events are also being added to the IBM Real-time Linux kernel.
TuningFork provides both on-line and off-line visualization of real-time events, with capabilities to play, rewind, zoom, and pause the execution. Based on user interface principles of consistency, perceptual stability, and direct manipulation, TuningFork provides an intuitive and powerful tool for visual and quantitative exploration of real-time data.
The basic TuningFork abstractions are Feeds, Streams, Filters, and Events. Feeds are sources of data, typically the trace of an execution of a program on the J9/Metronome virtual machine. However, there can be multiple feeds: the virtual machine and the operating system, or multiple virtual machine executions, or even synthetic feeds such as a simulated model of the virtual machine's behavior running inside of TuningFork.
Events record an occurrence at a particular time in the execution of the system. Events may be primitive, meaning that they were generated directly by the trace source, or synthetic, meaning they were generated as a function of one or more events by a Filter.
Filters take one or more event streams and can remove, add, or generate new events that are functions of their inputs. Filters may be simple, such as those that remove all but a single class of event, or complex, such as those that compute derivatives or convolutions.
Streams contain evolving streams of events which are passed on to filters or to visual displays.
TuningFork can also be used in an off-line, text-based mode to perform regression testing. A command interpreter, the conductor, interprets score files that can create textual or binary output in formats suitable for use by other tools.
SOFTWARE
TuningFork is available for download from the IBM alphaWorks.
PUBLICATIONS
David F. Bacon, Perry Cheng, Daniel Frampton, David Grove Matthias Hauswirth, and V.T. Rajan,
On-line Visualization and Analysis of Real-time Systems with TuningFork.
Proceedings of the Fifteenth International Conference on Compiler Construction, (Vienna, Austria, March 2006), Lecture Notes in Computer Science, Lecture Notes in Computer Science volume 3923, pp. 96-100.
PDF
EXAMPLES
Figure 1
The histogram and time series views of TuningFork. The histogram shows the length of the pause times ("beats") of the Metronome garbage collector, color-coded by the executing phase of the algorithm. The logarithmic scale allows system tuning to focus on the worst-case pauses.
The time series shows the allocation rate of the program, computed on a virtual time axis in which the time periods during which the collector was running have been removed by a "Snip" filter. Allocation rate is computed from memory usage events via a derivative filter, and then rates over various time scales are computed using a convolution filter. The visualization makes it easy to see that while allocation rates vary wildly at short time scales, they are highly stable at long time scales, a key observation for the Metronome garbage collection technique.
Figure 2
A time series view showing the real-time behavior of the Metronome garbage collector. Mutator utilization (red) is shown with periods of concurrent garbage collection activity highlighted in the background (yellow), which makes it easy to see how the utilization drops while collection is in progress -- but never below the guaranteed utilization rate of 70%.
Allocated memory (blue) is also plotted, and one can see that when the program reaches phase boundaries at which large amounts of the data are no longer used, the garbage collector runs very quickly and frees large amounts of memory.
Figure 3
An "oscilloscope" view, which is used for viewing very high-frequency events, of the execution of an Eventron running at 22.05 KHz and generating unbuffered audio. Each "strip" shows 181 microseconds of execution, or four 45 microsecond periods of Eventron. Each blue bar represents an execution of the Eventron, and the red blips are the Metronome "beat" scheduler.
100 strips are shown, allowing the visualization of 18 milliseconds of data. It can easily be seen that there are a number of Eventron executions which either begin late or take too long to execute. These are due to interference from the Linux clock interrupt handler.