[abc] OOPSLA paper

I have spent this morning going over the OOPSLA paper - overall it
looks good, but I do have some comments/questions.

Abstract
--------

Should abstract have citation in it? If so, could cite work by
Douence et. al. and Walker and Viggers and abc.

Introduction
------------

Citation on first use of "AspectJ" in intro.

Section 2
---------
Just before section 2.1 -
Some how I think we should emphasize more the fact that the sym declarations
are defining the alphabet on which traces will filtered, and then the
pattern is matched on this filtered trace. I know that this is explained,
but it sort of comes at the end of the description. It seems to me, by
lookin:w
g at examples later on, that when designing a tracematch, it is
really important to decide on which symbols to filter on, because this
impacts which traces are actually matched. Thus, I think it is reasonable
to describe a tracematch as first definining the set of symbols of interest,
which provided the filtered trace, and then definining the reg expr on
this filtered trace.

Section 2.1
-----------
Why do we use "==" instead of some more abstract equals for checking for
consistent variable bindings?

This surfaces again in Section 3.4. It seems the explanation is here -
should there be a forward pointer to it from section 2.1? In the explanation,
I don't understand the last sentence. Do you mean that one should bind
to different variables, and then use equals on those variables?

Safe Iterator Example
----------------------

use if e.g. a bit awkward?

Connection management example
------------------------------

- give page numbers in citation to Laddad's textbook?

Section 3.6
-----------
The following sentence ... "The second is to create a single trace
over the entire program, by interleaving the events of each thread." ...
is a bit confusing to me. Is it that you just observe the
events as they occur, forcing serialization of filtered events by
using synchronized operators?

Where in the semantics is this behaviour for multiple threads exposed?

Section 4.6
-----------

funny comma after definition of lab(s,t) - is that how you want it?

Section 5
---------

In Section 5 it states the "tracematches cannot bind values of primitive
types". I think this is the first place I have seen this restriction.
In section 3.4 you talk about testing equality of primitive types, so
it would seem that primitive values are allowed - what am I missing?

Performance section,
  four version of the program -> four versions of the program
  carefully code -> carefully coded

Section 6
---------

I'm not certain about the discussion of analyses needed to further
optimize tracematches using static analysis. In some sense, this seems
to be hitting exactly the same problems as those faced by people who
build static checkers for properties ... and the problems seem just
as hard.

So, I'm not sure what this discussion is supposed to convey. Is it
to say that further optimizing tracematches will require a hard analysis,
yet to be defined?

In the discussion of alias information, it is stated that one needs
to know whether a variable points to the same location at two different
points in the program. For store-based analyses, i.e. those that give
names to locations, this can be done by using the names. For example,
if s points to "new_1" at program point A and t points to "new_1" at
program point B, then there is a possible dependence. We already
do that for side-effect and dependence analysis in Soot using the alloc
sites - although these are "may" relationships.

There are also "storeless" pointer analyses, such as those developed in
my Ph.D. thesis, and then later by my student Rakesh Ghiya. In these
cases you don't have names, like "new_1", but only relationships between
variables at a program point. In his work (see POPL98 and his thesis) he
showed how to inject enough new variable copies so that the relationships
between variables at different program points could be compared, and he
then used that info for optimizing C pointer programs.

I mention these things not because I think we need to address them in the
paper, but to point out that when we start talking about static analyses
like these there is a lot of related work ... and perhaps we just want to
say something a little more high-level and not get into details...

The other approach - storeless

+-------------------------------------------------------------+
| Laurie Hendren, Professor, School of Computer Science |
| McGill University |
| 318 McConnell Engineering Building tel: (514) 398-7391 |
| 3480 University Street fax: (514) 398-3883 |
| Montreal, Quebec H3A 2A7 hendren@cs.mcgill.ca |
| CANADA http://www.sable.mcgill.ca/~hendren |
| http://wwww.sable.mcgill.ca http://aspectbench.org |
+-------------------------------------------------------------+
Received on Mon Aug 1 16:22:19 2005