Traveler: trace navigator (experimental)

experimental version of 1999.10.11
Copyright (c) 1999 Massachusetts Institute of Technology.
This software is provided "as is" without express or implied warranty.

• to trace/record the history of execution of concurrent programs, and
• to browse/navigate these records
  • as nested call outlines, i.e., the activation order within threads, and
  • as linear object biographies, i.e., the entry order of synchronization at objects.

Nested activities: Traveler displays thread activity as a familiar trace of nested activities. FutureFactorial computes factorial as a product of the range of integers from 1 to n, illustrating a concurrent recursive divide and conquer on the range of integers to be multiplied. Each call to rangeproduct shown at right is from a separate thread of a future, so here the nested calls are concurrent.

Biographies: Threads may interact through shared objects; in Java, they usually access shared objects via synchronized methods and blocks. The outcome may therefore depend on the order in which the threads enter synchronized regions. At the right is part of the biography of an Account from which threads have concurrently made deposits and withdrawals. [image from earlier version.]

Traveler provides means to navigate from nested call renderings to biography renderings and vice versa.

Applet: Try the Traveler applets page to explore these capabilities on the examples.

See Traveler javadoc for more details.

Traveler Release Notes

1999-07-05: Added alternate trace recorder, TraceRecorderObservable, and its associated classes, which incrementally update display of an activity's direct children and display of biography's activities as a program progresses. See also for example code using it (initialized at bottom in initFrameApplet).

1999-06-09: first experimental release.

Prior and Related Systems

• Hierarchical records: For Java, thread calls are recorded as hierarchical activities. Each call record incrementally records the invocation, nested calls (and parent), and result (return or throw). For Acore, a net of message arrival events is recorded. An event record records the arrival of a single invocation or return/exception message. Each event record also records the events it activated (and its activator), transitively recording the activation order among events (a partial order), augmented with call pairing of an invocation event with its return/exception event. Both the hierarchy of Java activity records and the net of Acore event records are displayed in similar ways, as an expandable trace of nested calls. The hierarchical records are simpler to navigate, and may consume less memory. Recording an event net is more localized, and may consume less communications in a distributed system.
• Entry vs. Arrival order: Java's lightweight synchronization does not require that threads enter synchronized methods or synchronized blocks in their arrival order, so the biographies of activities at each object should be recorded upon entering synchronized methods or blocks (or regions protected by some other higher level synchronization mechanism). For Acore, messages to serialized actors are always processed in the order they arrived (first-in, first-out), so biographies record the arrival order of messages.
• Nesting: Java threads may enter nested synchronization blocks before exiting (e.g., when a synchronized method calls another synchronized method), or may enter a nested wait to temporarily release those synchronizations and allow other threads to enter. Biographies for Java thus record ordering among all the entries and exits, while Acore biographies only record arrivals.
• Recording technology:The current facilities for tracing Java programs are to run the program using Jeva (interpreting source code with an evalhook), or to manually add tracing code to a Java program and compile it. The Acore system relies on hooks in the Actor Machine Emulator to make records when the message and/or the actor are tagged to be recorded. A similiar system for Java would require hooks in the virtual machine, perhaps like the meta object hooks provided by metaXa (MetaJava). An alternative would be to automatically add tracing code to the Java program, perhaps as in the class-based compile time reflection of OpenJava.
• No filtering afterward: The current facilities for navigating records of Java program activity do not include ways of filtering the records displayed that are in the Acore system (in effect providing a selective trace after the fact). The Acore filtering was seldom used, partly because it was usually much faster to trace selectively than to use full recording and then filter. Filtering would be much more important in situations where is is not possible or not practical to re-run the program.
• No stepper: the Acore system was integrated with a concurrent stepper and updated the display as concurrent activities completed.