Re: [abc] oopsla outline

On Tue, Mar 14, 2006 at 08:41:24AM -0500, Ondrej Lhotak wrote:
> On Tue, Mar 14, 2006 at 08:34:06AM +0000, Oege de Moor wrote:
> > The section on "contains" would perhaps be better if we give a better idea
> > what the analysis of the pattern for LUInMeth would do. Can we provide a
> > little more detail than what's there now?
>
> Neil added that section. I will coordinate with him and add detail
> about the possible analyses we could do.

The LUInMeth example led to a big discussion about the confusing
semantics of cflowbelow (with relation to filtering) in tracematches.
I won't repeat the discussion here, because it was rather long, and
doesn't really help to get this particular section of the paper
finished. See irc logs if you're interested in the details.

Unfortunately, I couldn't catch Neil on irc, so I talked it out with
Eric instead. So, Neil, if you're around, it would be helpful if you
could confirm whether we understand your intentions correctly.

The general point of the future work section on contains (7.3) seems to be
that, if we have a tracematch like "enter lock exit", we would like to
not do any work at runtime for matches of "enter" which we know will
never result in a complete match. In this case, I think this kind of
analysis is subsumed by the analyses described in the following section
(7.4). For the specific tracematch in Figure 8, which relies on nasty
dynamic pointcuts like let and cflowbelow, the static analysis would
have to additionally include static analysis of these dynamic pointcuts.
But, it seems that this is just a distraction from the point that Neil
was trying to make: we want an analysis that removes the work needed
to be done at events that we can prove will never lead to a match.

So, I propose moving the stuff currently in 7.3 into 7.4, and using
it as an example of the kind of thing we would like achieve with
the static analysis.

Does this make sense?

Ondrej
Received on Wed Mar 15 16:21:00 2006