RE: [abc] oopsla outline

Hi, I had hoped for another kind of change. In the LUInMeth example, it
appeared to me the insertion of "contains" can be derived from the
tracematch alone, *without* ever considering the base program. By contrast,
the discussion in 7.4 seems to focus on using a static analysis of the base
program we're instrumenting. Furthermore, I could imagine the technique
being more generally useful, restricting symbol pointcuts based on the way
they are used in the tracematch pattern. Am I wrong? Does the insertion of
contains actually require an examination of the base program? True, it might
be a difficult analysis to do, but if it only analyses the tracematch one
can afford some pretty expensive algorithms!

While on the subject of 7.4, the discussion of related work seems somewhat
light to me. Why are we highlighting Bandera's use of slicing? It's bizarre
to cite [7] as the main source for Bandera. [7] is a crap paper without
scientific interest - please cite the original source by Dwyer & Hatcliff.
What about the papers by Dawson Engler, Manuvir Das, Sriram Rajamani & Tom
Ball, all of which deal with a trace specification as a regular pattern, and
then find the matching shadows in the code? We should at least show an
awareness of these.

-Oege

> -----Original Message-----
> From: Majordomo list server [mailto:majordomo@comlab.ox.ac.uk] On Behalf
> Of Neil Ongkingco
> Sent: 16 March 2006 07:01
> To: abc@comlab.ox.ac.uk
> Subject: Re: [abc] oopsla outline
>
> Yes it does seem to be a subset of the static analysis proposed in 7.4.
> I have turned it into a paragraph in the Static match analysis section
> as an example which the experiments have shown does provide a
> considerable speedup. You can check to see if it fits in the flow of
> that section.
>
> Neil
>
> Ondrej Lhotak wrote:
> > 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 Thu Mar 16 07:33:13 2006