TuningFork     

links

 Erik Altman photoDavid Grove photo

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