Re: [abc] oopsla outline

From: Neil Ongkingco <neil.ongkingco@keb.ox.ac.uk>
Date: Thu Mar 16 2006 - 07:01:22 GMT

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 06:59:26 2006

This archive was generated by hypermail 2.1.8 : Tue Mar 06 2007 - 16:13:27 GMT