Re: [abc] oopsla outline

In LUinMeth it does seem to be the case that you can restrict the extent
of symbols by just looking at the tracematch, but in general I believe
that it would be easier to prove that such a restriction preserves the
behavior of the tracematch for a specific base program that to prove
that it will preserve behavior over any base program. What I'm not sure
of is how often these special cases (of being able to optimize the
tracematch without looking at the base code) occur, how useful these
types of tracematches are, and whether it would be worth adding a
separate analysis for detecting and optimizing such cases.

Neil

Oege de Moor wrote:
> 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 11:23:32 2006