[e-lang] Fwd: a couple of points about Causeway
cocoonfx at gmail.com
Sun Mar 23 23:21:16 EDT 2008
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
(This is 1 of 3.)
---------- Forwarded message ----------
From: Terry Stanley <cocoonfx at gmail.com>
Date: Wed, Feb 27, 2008 at 9:21 PM
Subject: a couple of points about Causeway
To: Dean Tribble <dtribble at gmail.com>, Tyler Close
<tyler at waterken.net>, kpreid at mac.com, warner at lothar.com
Cc: Mark Miller <erights at gmail.com>, Terry Stanley <cocoonfx at gmail.com>
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
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
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.
More information about the e-lang