Database model of TOD

This page explains what information does the TOD database store, and how this information can be accessed.

In TOD, an execution trace is a flat list of events. There are different kinds of events: behavior call, exception generated, field write, local variable write, etc. Note that currently the only cflow-altering events that are captured are behavior call and exception generated; we do not yet capture the outcome of conditions like if or while (except in the case of instanceof tests in the dynamic residue evaluation of pointcuts when the AspectJ extensions are used, but that’s another story…).

Each event has a set of attributes. Some attributes are common to all event types (eg. timestamp, thread…), while others are specific to a particular event type (eg. behavior id, target and arguments for behavior call, field id, target and value for field write, etc.).

In the execution trace, each runtime object is assigned an id.

The database API supports two low-level queries, and a handful higher-level queries, described below.

Low-level queries

• Cursors

A cursor is like an iterator that permits to retrieve events that match a specific criteria, or filter, based on its attributes. For example, it is possible to obtain a cursor that retrieves all the events that occurred in a particular thread and at a particular control flow depth, or all the behavior call events that corresponds to calls to either foo or bar on a given object.

Cursors can be efficiently moved to any position in the event sequence, and can iterate either forward or backward.

• Counts

This query counts the number of events matching a certain criteria (ie. those that would be returned by a cursor with the same filter) that occur during a time interval, or during a each slot in a series of consecutive, equally-sized subdivisions of a time interval. They are used to implement the high-level overviews (aka. activity overviews, aka murals) in TOD.

Higher-level queries

• Object reconstitution

Permits to retrieve the values of the fields of a given object at any point in time.

• Stepper

Helps in implementing the classical stepping behavior (step into, step over, step out) of traditional debuggers.