Fwd: a couple of points about Causeway

Tyler Close and I have been working on defining a general,
language-neutral trace file format for Causeway. The focus of this
effort has been on tracing Waterken applications. But a longer term
goal is for Causeway to support debugging asynchronous message-passing
programs, in general.

I'm forwarding some of our email (with Tyler's permission) for review
and discussion.

(This is 1 of 3.)

--
 --Terry

---------- Forwarded message ----------
From: Terry Stanley <[email protected]>
Date: Wed, Feb 27, 2008 at 9:21 PM
Subject: a couple of points about Causeway
To: Dean Tribble <[email protected]>, Tyler Close
<[email protected]>, [email protected], warner-rGj/[email protected]
Cc: Mark Miller <[email protected]>, Terry Stanley <[email protected]>


A question came up recently that I would like to try to answer.

 In some situations tracing is expected to be useful, but stack
 walkbacks are too expensive. For example, generating a trace on a
 production system should incur minimal overhead. The question is, how
 well does Causeway present message flow without stack information.

 To test this, I launched Causeway with a set of trace files. Then I
 manually edited copies of those trace files and removed all stack
 information and launched a second Causeway on these stackless trace
 files. The message flow in the Message pane (outline view) looked
 almost identical. In particular, cross-vat messages were stitched up
 properly.

 Speaking of stitching ...

 Causeway parses trace files and builds (what I call) a raw graph.
 Then, a "relevance function" is applied to nodes of the raw graph to
 determine how to transform it to (what I call) a pruned graph. There
 are also a few additional ad-hoc transformations. The relevance
 function and other transformations used for E came about
 little-by-little in an attempt to present interesting causality,
 without a lot of noise. For E programs this meant:

    - Filtering out events involving only E infrastructure code. Since
 we were tracing E and much of the E infrastructure is written in E,
 this code necessarily showed up in the trace files.

    - Removing uninteresting messages while keeping the interesting
 ones. For example, messages related to promise resolution are not
 interesting at the application level, while messages related to
 when-catch construct are.

    - Stitching up cross-vat messages. In the raw graph, an "ether"
 object holds on to the send-side stack (if there is one). This is the
 stack at the time the message was sent. The pruning algorithm walks
 the graph to find the local message send on the exec-side. The stack
 information is attached to that object and the ether object is removed
 from the graph.

 This is not a complete list of transformations, nor is it a precise,
 complete description. I'm just trying to give you an idea of what kind
 of effort will be necessary once you've got the (Waterken, Twisted,
 E-on-CL) traces. When Dean, MarkM, and I were looking at the first
 traces generated by E in Causeway (a couple of years ago) we were
 totally baffled. The work involved to get to a coherent, pruned
 message tree is delicate and can only be done with some understanding
 of the system being traced. If it's done well, many developers will
 benefit. Fortunately, most of the work can probably be expressed as an
 alternate relevance function rather than as direct graph
 transformations.

 I will explain about these transformations in more detail later. But I
 wanted to give you guys a heads-up now that you shouldn't be surprised
 if you need to write such filters and transformers before Causeway's
 visualizations of your traces becomes useful.

 --
  --Terry