Re: [abc] PLDI paper

I wonder if we should make the point earlier on that it is
hard to design an analysis on unwoven code, because any such
analysis would have to know the effect of weaving, which is
itself is quite complex?

You do make that point, but at first it seems to be just a matter
of convenience (using Soot) that we want to analyse after the
weaver and really it is a fundamental problem in designing any
flow analysis for AOP - you really need to analyze the woven
code.

At the end of the section, I think you are referring to boxes with
old names, perhaps?

I don't know if I am making sense, I'm a bit tired. Will start again
early tomorrow.

Cheers, Laurie

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

On Thu, 14 Apr 2005, Ondrej LHOTAK wrote:

> On Thu, Apr 14, 2005 at 04:19:10PM +0100, Oege de Moor wrote:
> >
> > I went over this section, and found a couple of places where
> > the old definition still lurked in the paper, so I've
> > changed those.
>
> Yes, those fixes are good. Thanks, Oege.
>
> > Following a brief discussion with Laurie, I've also updated
> > the account of reweaving in 4.2.1 substantially, also
> > replacing the figure.
> >
> > Let me know what you think!
>
> The new reweaving stuff is very nice. Great!
>
> Ondrej
>
> >
> > -O
> >
> >
> > On Tue, 12 Apr 2005, Ondrej Lhotak wrote:
> >
> > > On Sat, Apr 09, 2005 at 08:35:32PM +0200, Damien Sereni wrote:
> > > > > 8) Damien mentioned a variation of our inter-proc algorithm ... Damien ...
> > > > > what was it - something about not needed something on "all paths"?
> > > >
> > > > I just noticed in chicago that the condition for setting a cflow
> > > > residue to alwaysMatch is stronger than it needs to be -
> > > >
> > > > what i would expect would be
> > > > a query shadow qsh is statically true if for every interprocedural
> > > > path p to qsh there is an update shadow in p
> > > > [where an interprocedural path includes calls but not returns]
> > > >
> > > > whereas the condition that there is an update shadow sh such that qsh
> > > > is in mustCflow(sh) is equivalent to :
> > > > every interprocedural path p to qsh goes through sh [ie all paths must
> > > > go through the same shadow]
> > > >
> > > > (please check that i haven't made some mistake along the way!)
> > > >
> > > > I guess the mustCflow version is probably easier / more efficient to
> > > > compute, but maybe we should mention the other one (of course, the
> > > > benchmarks show the mustCflow is precise enough)
> > >
> > > I've updated the discussion of mustcflow in the paper to match the
> > > code (which implements the improved condition which Damien describes
> > > above) and checked it in. I'd appreciate it if someone had a look at the
> > > discussions of mustcflow to make sure that they make sense.
> > >
> > > Ondrej
> > >
> > > >
> > > > Cheers,
> > > > Damien
> > > >
> > >
> >
>
Received on Fri Apr 15 02:44:13 2005