Re: [abc] OOPSLA paper

Thanks Laurie! As said, I'm taking a break, and Pavel is busy
with the implementation, so if these changes are to be made,
it will have to be done by someone else.

Quick responses below.

-Oege

On Mon, 1 Aug 2005, Prof. Laurie HENDREN wrote:

> 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.

I don't think abstracts need to have citations

> Introduction
> ------------
>
> Citation on first use of "AspectJ" in intro.

yes

>
> 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.

fine, I think it's clear as it stands, but if you can think of
a better wording, please do.

> 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?

yes, possibly. Of course this is true of all the design decisions that
are further elaborated in Section 3...

> 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?

yes

>
>
> Safe Iterator Example
> ----------------------
>
> use if e.g. a bit awkward?

yes

> Connection management example
> ------------------------------
>
> - give page numbers in citation to Laddad's textbook?
>

yes

>
> 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?

correct

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

It's independent, because the semantics directly refers to traces.
How these are generated, by one thread or multiple threads, is neither
here or there.

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

I'm fine either way. It's very common to punctuate in this way
in maths texts...

> 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?

The current implementation forbids primitive values because of the
potential for space leaks. I suggest we update 3.4 to be in line
with the implementation

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

yes

> Section 6
> ---------

Laurie, I've brought this up a number of times. This section is the
main McGill contribution to the paper - it was written by Ondrej.
If you're willing to rewrite it - as I've asked in a previous email,
that would be great... if there's no time to do that, I don't
think it does major harm.

In the story of the whole paper, I think it is important to have
the section (with some level of detail), to assure the reader
that one day tracematches could be even more efficient than the
pure AspectJ versions...

> 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 Tue Aug 2 12:54:52 2005