On Tue, Aug 09, 2005 at 01:00:06PM -0400, Laurie Hendren wrote:
> All other authors, we need some proof readers. Who is available to
> go through the paper carefully?
I've just finished a complete pass over the paper. I made many minor,
non-controversial fixes (spelling, typos, commas) and checked them in;
I've attached a diff at the bottom of this e-mail. There were two
problems that I noticed that I did NOT fix. They are:
1) The graph in Figure 6 seems to have a gray background, rather than
white. The background extends quite far to the right of the actual
graph, so much so that it covers over part of the right column of text!
How was the graph created? Can it be changed to have a white background,
or can it be cropped where the graph ends, so that the over-extending
background doesn't cover the text?
(This problem doesn't seem to appear when viewing the paper on the
screen, only when it is printed.)
2) In Related Work, near the end of the section on Douence et al, is
the phrase "in that paper, the code is LITTERED with explicit equality
tests". Were we supposed to be nice to them in the related work? Is
"littered" the word we want to use?
Ondrej
Here's the diff:
Index: Text/abs.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/abs.tex,v
retrieving revision 1.7
diff -u -r1.7 abs.tex
--- Text/abs.tex 18 Jul 2005 16:48:46 -0000 1.7
+++ Text/abs.tex 10 Aug 2005 14:44:00 -0000
@@ -28,18 +28,18 @@
are confined to the {\em current} action: it is not possible to
directly observe the {\em history} of a computation.
-Recently there have been several interesting proposals for new history-based
+Recently, there have been several interesting proposals for new history-based
language features, most notably
-by Douence {\em et al.} and also by Walker and Viggers. In this
-paper we present a new history-based language feature
-called {\em tracematches}, where the programmer can trigger the execution
+by Douence {\em et al.} and by Walker and Viggers. In this
+paper, we present a new history-based language feature
+called {\em tracematches} that enables the programmer to trigger the execution
of extra code by specifying a regular pattern of events in a computation
trace. We have fully designed and implemented tracematches as a
-seamless extension to AspectJ.
+seamless extension of AspectJ.
A key innovation in our tracematch approach is the introduction of free
variables in the matching patterns.
-This enhancement enables a whole new class of applications where events
+This enhancement enables a whole new class of applications in which events
can be matched not only by the event kind, but also by the values associated
with the free variables. We provide several examples
of applications enabled by this feature.
Index: Text/conclusion.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/conclusion.tex,v
retrieving revision 1.4
diff -u -r1.4 conclusion.tex
--- Text/conclusion.tex 14 Mar 2005 07:38:44 -0000 1.4
+++ Text/conclusion.tex 10 Aug 2005 14:44:00 -0000
@@ -13,8 +13,8 @@
for reasoning about the behaviour of tracematches. We also presented
an operational semantics as a step towards an implementation.
The main insight in defining the operational semantics was the
-need for a new symbol in the alphabet, to capture the skipping
-of other symbols, due to variable binding. The declarative
+need for a new symbol in the alphabet to capture the skipping
+of other symbols due to variable binding. The declarative
and operational semantics were proved to be equivalent. This
is quite a satisfactory result, because conceptually they are
quite different.
@@ -28,7 +28,7 @@
in the implementation, in particular regarding the memory usage of
tracematches.
We also identified a number of further optimisation opportunities.
-Some of these required advanced program analyses, and we intend to
+Some of these require advanced program analyses, and we intend to
report on careful performance experiments, involving those
advanced optimisations, in a companion paper.
Index: Text/design.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/design.tex,v
retrieving revision 1.31
diff -u -r1.31 design.tex
--- Text/design.tex 2 Aug 2005 12:25:12 -0000 1.31
+++ Text/design.tex 10 Aug 2005 14:44:01 -0000
@@ -446,7 +446,7 @@
are used to replace the original value of variables bound by the pointcut.
We provide an analogous feature in tracematches by the following mechanism.
An {\bf around}
-symbols can optionally declare a signature for {\bf proceed}()
+symbol can optionally declare a signature for {\bf proceed}()
by giving a list of tracematch variables after the {\bf around} keyword
(similarly to ordinary {\bf around} advice but without the types). The
actual values passed to {\bf proceed}() then replace the values at
Index: Text/impl.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/impl.tex,v
retrieving revision 1.29
diff -u -r1.29 impl.tex
--- Text/impl.tex 8 Aug 2005 12:33:13 -0000 1.29
+++ Text/impl.tex 10 Aug 2005 14:44:01 -0000
@@ -72,16 +72,16 @@
Our current implementation closely follows the exposition
in this paper, with an emphasis on correctness rather than
speed. In our experience, the tracematch version of the
-small examples presented earlier is typically a factor 15
+small examples presented earlier is typically a factor of 15 times
slower than the best hand-coded AspectJ version. The main
reason for this overhead is a purely functional implementation
of the constraint-handling code, which leads to substantial
-heap turn-over.
+heap turnover.
As a realistic example, we applied our safe iterator
tracematch to the use of {\em Enumeration} in {\em JHotDraw} \cite{jhotdraw},
when playing an animation in the {\em JavaDraw} application.
-The total size of the JHotDraw is 9422K SLOC.
+The total size of JHotDraw is 9422 SLOC.
We chose this application because it represents
a worst-case scenario for our techniques: if we were to
apply tracematches to database connection management, for
@@ -89,8 +89,8 @@
the use of tracematches.
As to the utility of this type of application, it turns out
that the use of {\em Enumeration} in JHotDraw is {\em not}
-safe, when the drawing is edited while an animation
-is in progress. Indeed, we discovered that violation by
+safe when the drawing is edited while an animation
+is in progress. Indeed, we discovered this violation by
running our tracematch.
For the measurements, we removed the timed slow-down in the
@@ -110,8 +110,8 @@
$1.4.2\_04$ under Debian Linux. We measured both the time
taken in seconds, as well as the total amount of heap memory used in
kilobytes. The memory measurements were taken by calling
-the garbage collector, and subsequently reporting the difference
-in the runtime between total and free memory.
+the garbage collector and subsequently reporting the difference
+between total and free memory.
\vspace{0.2mm}
@@ -127,7 +127,7 @@
\vspace{0.2mm}
-Note in particular the fact that the tracematch version
+Note in particular that the tracematch version
uses hardly more memory than the version with no aspect:
the techniques discussed above succeed in eliminating all
memory leakage. To verify that this is not an artifact of
Index: Text/intro.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/intro.tex,v
retrieving revision 1.10
diff -u -r1.10 intro.tex
--- Text/intro.tex 8 Aug 2005 12:33:13 -0000 1.10
+++ Text/intro.tex 10 Aug 2005 14:44:01 -0000
@@ -12,9 +12,9 @@
In AspectJ, pointcuts can only refer to the current program
state, or more precisely, the current joinpoint, including an abstraction
of the call stack. It is natural to explore a richer pointcut
-notation, which refers to the whole history of a computation,
-as a trace of the joinpoints encountered so far. There have been
-several such history-based approaches recently proposed. Walker and
+notation that refers to the whole history of a computation
+as a trace of the joinpoints encountered so far.
+Several such history-based approaches have recently been proposed. Walker and
Viggers have introduced the idea of {\em tracecuts} as a history-based
generalisation
of pointcuts \cite{walker04}. Other history-based proposals have been
@@ -111,7 +111,7 @@
particular regarding memory usage of compiled code.
\end{itemize}
-In what follows, we shall assume the reader has a nodding acquaintance
+In what follows, we assume the reader has a nodding acquaintance
with AspectJ, and in fact most of our pure AspectJ code should be
self-explanatory. There is a wealth of textbooks available on the subject,
including \cite{colyer04b,gradecki03,kiselev02,laddad03,miles04}.
Index: Text/optims.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/optims.tex,v
retrieving revision 1.7
diff -u -r1.7 optims.tex
--- Text/optims.tex 4 Aug 2005 16:02:49 -0000 1.7
+++ Text/optims.tex 10 Aug 2005 14:44:01 -0000
@@ -9,7 +9,7 @@
that our design makes possible, and that we intend to implement in the
future.
-The state that a tracematch implementation must represent at run-time is
+The state that a tracematch implementation must represent at run time is
a set of configurations of the form $(q, \sigma)$, where $q$
is a state of the machine $M$ matching $Pat$, and
$\sigma$ is the partial substitution of actual run-time values
@@ -21,7 +21,7 @@
$\sigma$
is updated with any new bindings implied by the match.
In optimizing the implementation
-of tracematches, our goal is to reduce the size of set of configurations
+of tracematches, our goal is to reduce the size of the set of configurations
that must be maintained
by removing configurations which can be proven to never lead
to an accepting state.
Index: Text/related.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/related.tex,v
retrieving revision 1.14
diff -u -r1.14 related.tex
--- Text/related.tex 26 Jul 2005 15:54:31 -0000 1.14
+++ Text/related.tex 10 Aug 2005 14:44:01 -0000
@@ -62,7 +62,7 @@
pointcut. In our setting, this would mean that every symbol declaration has
an associated piece of code. Clearly this is very powerful, but it
also makes it very difficult to track what is happening in the matching
-process, especially when the advice has side effects. In cases where such
+process, especially when the advice has side-effects. In cases where such
behaviour is needed, we could use two tracematches instead of one.
A second important difference concerns the treatment of the choice operator.
@@ -80,7 +80,7 @@
work, we are fairly confident that their results can be transferred
to our setting, and implemented in {\em abc}.
-There exists at least two implementations that were loosely inspired
+There exist at least two implementations that were loosely inspired
by the design of Douence
{\em et al.}, namely in JaSCo \cite{vanderperren05} (an integration
with Java), and in the Arachne system \cite{douence05}. Applications
@@ -99,9 +99,9 @@
interesting, therefore,
to compare our design decisions to theirs.
-An obvious difference is that their design uses an extension of context free grammars
+An obvious difference is that their design uses an extension of context-free grammars
to define the set of traces to match, rather than the regular expression presented
-here. The set of languages used are not strictly context free, however. A 'semantic action
+here. The set of languages used are not strictly context-free, however. A 'semantic action
block' can be associated with each token, to be executed whenever a current joinpoint
matches a token. This block has access to information about the trace
matched so far and can reject a match using the \verb+fail+ keyword, which
@@ -112,7 +112,7 @@
while it is trivial to decide whether one regular language is included in another,
the problem is undecidable for context-free languages.
-These semantic action blocks can also have side effects, which complicate the relationship
+These semantic action blocks can also have side-effects, which complicate the relationship
between the tracecuts and the original program. Without side-effects, a tracecut simply
observes the execution of the base program until the point where a match is discovered
(so if a match is never found then the behaviour of the program is not altered.)
@@ -186,15 +186,15 @@
compile-time, the error message is printed. An obvious generalisation
is to provide trace versions of these constructs, and then the
formalism is very close in expressive power to the works cited
-above. Such a feature would require a static analysis similar to the
+above. Such a feature would require a static analysis such as the
one discussed in Section~\ref{OPTIMISATIONS}.
-In this respect we are particularly encouraged by the success
+In this respect, we are particularly encouraged by the success
of program query languages such as PTQL \cite{goldsmith05} and PQL \cite{lam05}.
In these systems, one writes queries over program traces; and these
queries are evaluated by instrumenting the object program.
Advanced static analyses are used to minimise the overheads of the
-queries. In the case of PTQL the queries are phrased in the style
+queries. In the case of PTQL, the queries are phrased in the style
of SQL, whereas PQL is based on DataLog. Neither of these adopts the
declarative semantics for tracematching we have proposed in this
paper, filtering the traces to include precisely those events that
Index: Text/semantics.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/semantics.tex,v
retrieving revision 1.29
diff -u -r1.29 semantics.tex
--- Text/semantics.tex 17 Mar 2005 23:04:59 -0000 1.29
+++ Text/semantics.tex 10 Aug 2005 14:44:01 -0000
@@ -178,7 +178,7 @@
in the base program, we match it against each of the symbols,
and make the corresponding changes to the flags: if there is a
transition from $s'$ to $s$ labelled with symbol $a$, if the flag on $s'$
-is set to true, and if $a$ match the new event $e$, the flag on $s$ is set to true.
+is set to true, and if $a$ matches the new event $e$, the flag on $s$ is set to true.
If no such transition to $s$ exists, the flag on $s$ is set to false.
When a final state becomes reachable, advice is executed.
Index: Text/semdecl.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/semdecl.tex,v
retrieving revision 1.15
diff -u -r1.15 semdecl.tex
--- Text/semdecl.tex 26 Jul 2005 16:51:14 -0000 1.15
+++ Text/semdecl.tex 10 Aug 2005 14:44:01 -0000
@@ -14,7 +14,7 @@
We shall model variable bindings as \emph{constraints}, that is
equations
%of the form $x=v$ (for a variable $x$ and a value $v$),
-combined with the usual logical connectives. In particular a
+combined with the usual logical connectives. In particular, a
constraint may be an equation between a variable and a runtime
value, $x=v$, or an inequation, $\neg(x=v)$. We write $C$
for the set of all constraints. For a given tracematch, the
Index: Text/semimpl.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/semimpl.tex,v
retrieving revision 1.8
diff -u -r1.8 semimpl.tex
--- Text/semimpl.tex 19 Jul 2005 12:05:09 -0000 1.8
+++ Text/semimpl.tex 10 Aug 2005 14:44:01 -0000
@@ -1,6 +1,6 @@
This abstract reference implementation may, at first sight, appear
-expensive. Note, however, that in AspectJ most of the pointcut matching
-the computation of $a(e)$ can be carried out statically
+expensive. Note, however, that in AspectJ, most of the pointcut matching
+in the computation of $a(e)$ can be carried out statically
\cite{masuhara03a}, and consequently the above transition from
$\LAB$ to $\LAB'$ is also mostly static: it can be pre-computed
at compile-time, except for variable bindings.
Index: Text/semtoimpl.tex
===================================================================
RCS file: /mnt/msproj/shared/cvs/oopsla05/Text/semtoimpl.tex,v
retrieving revision 1.8
diff -u -r1.8 semtoimpl.tex
--- Text/semtoimpl.tex 28 Jul 2005 13:27:38 -0000 1.8
+++ Text/semtoimpl.tex 10 Aug 2005 14:44:01 -0000
@@ -123,7 +123,7 @@
\neq \textit{true}$, and in this case the computed
$\LAB_{\textit{impl}}(s,te)$ constraints are valid for all states $s$.
-Our strategy upon occurrence of a new event $e$, then
+Our strategy upon occurrence of a new event $e$, then,
is to first compute $\SKIP(e)$, and subsequently to apply
the above formula (if one of the tracematch declared symbols matched).
Received on Wed Aug 10 15:45:26 2005
This archive was generated by hypermail 2.1.8 : Wed Aug 10 2005 - 20:50:11 BST