Cedar offers a dynamic memory facility. Any process can request a new chunk of memory. There is a garbage collector that will automatically reclaim unused chunks of memory every now and then. This tool concerns itself with the number of words of memory used; it does not concern itself with the number of objects (chunks) or how the words are divided among them.

The dynamic memory activity can thus be summarized as a sequence of pairs <ti, Dmi>, where ti is the time of an event and Dmi is the change in number of words of dynamic memory in use. A running average is a summary of this sequence (an Infinite-Impulse-Response filter, for you EEs). The running average of this sequence up to time tf is

where the parameter "t", which might be called the `half-life', controlls how fast old data are forgotten about. The half-life needs to be chosen with some care. If it is too short, the discontinuous nature of the activity of the garbage collector makes the average bounce around too much. If it is too long, it is hard to blame the current average on an interestingly specific period of time. The MemoryMonitor gives the user the opportunity to maintain several averages, each with its own user-changeable half-life.

The MemoryMonitor does not actually fondle each dynamic memory event; instead it samples the total activity every so often. It pretends that all the activity during the sampling period happens in one instant at the end of the sampling period. The half-life should be kept in mind when choosing a sampling period. If the sampling period is too short, new activity contributes so little to the average that it gets lost in the finite precision of floating point arithmatic. On the other hand, if the sampling period is too long, the most recent sample dominates the average to the virtual exclusion of all past samples. The MemoryMonitor strongly recommends that the sampling period (s) and the half-life (t) satisfy

In fact, it is recommended so strongly that the MemoryMonitor refuses to set them otherwise.

Here's a recipe for making a MemoryMonitor tool:

The above recipe will produce a tool that looks like this:

For each pair of sampling-period and half-life variables, the MemoryMonitor maintains and presents three averages: one of words allocated, one of words reclaimed, and one of the net words consumed (i.e., words allocated minus words reclaimed). They are displayed from top to bottom, in that order. Their magnitudes are displayed on a logarithmic scale; their signs are not presented.

The sampling-period and half-life variables are displayed and modified through screen buttons. They are displayed as "hours:minutes:seconds". A click with the left mouse button doubles the value, a right-click halves, and a middle-click sets to a "reasonable" value --- for half-life, this is the original value; for sampling-period this is the minimum acceptable value.

The number of pairs of sampling-period and half-life variables is set by the user when the tool is created, as are the initial half-lives. The initial sampling-periods are chosen to be the minimum acceptable values. When creating a MemoryMonitor tool, the user also has the choice of placing tick marks and labels across the top, or the bottom, or both, or neither. Here's the creation procedure's interface: