Re: [abc] Dataflow analysis

Clearly there are a lot of people interested in static analysis
of runtime properties ... which atm is showing itself wrt tracematches.
I asked Eric to send out the message as a way of trying to build
this plan.

We must be careful to overlap where it makes sense and to carve
out bits for theses. I think Eric's interest comes from trying
to improve the performance of J-LO (using both static analysis and
dynamic VM stuff), and Ondrej's interest comes from
applying context-sensitive analyses and using his frameworks in new
ways (which is also what Nomair is saying I think), and the Oxford
boys want to continue their work on improving tracematches which they
have been working on for some time already.

Considering that over 100 papers have been written on variations of
points-to and shape analysis, I am sure there is a lot of territory
to share on the general area of static analysis of runtime properties,
while at the same time building some common infrastructure.

So, we should try and identify the common bits and the individual
bits so that we make the most progress and also leave enough for
everyone's Ph.D. thesis.

Cheers, Laurie

ps.
For the case of Nomair, he is currently working hard on his decompiler
and it will depend on where he goes for his Ph.D. studies exactly
what he will end up up doing - he doesn't start his Ph.D. until
next September ... so I think he can join in and figure out his turf
at that time.

+-----------------------------------------------------------------
| Laurie Hendren --- laurie.hendren@mcgill.ca
| Associate Dean (Academic), Faculty of Science,
| Dawson Hall, McGill University, 853 Sherbrooke St W,
| Montreal QC H3A 2T6 Canada, 514-398-7179, fax 514-398-1774
+----------------------------------------------------------------
| For contact and home page info as Professor, Computer Science:
| http://www.sable.mcgill.ca/~hendren --- hendren@cs.mcgill.ca
| Research: http://www.sable.mcgill.ca http://aspectbench.org
+----------------------------------------------------------------

On Sat, 28 Jan 2006, Ondrej Lhotak wrote:

> I'm interested in static analysis of tracematches.
>
> Also, Nomair wrote that he wants to do this sort of thing for his PhD,
> so if you're looking for people to discuss it with, I'd suggest
> talking to him.
>
> Ondrej
>
> On Fri, Jan 27, 2006 at 12:02:48PM -0500, Eric Bodden wrote:
> > Hi all.
> >
> > I have just had a meeting with Laurie and we discussed my plans for my
> > thesis. So my long term goal is to provide a verification tool that uses
> > something like the existing implementations of tracematches and/or J-LO
> > as a backend, and then some (probably domain specific) high level
> > formalisms which allow users to specify real life properties about their
> > applications. The point is that the implementation should be fast. In
> > fact I want to try as much as I can to speed up things both trough
> > static analysis and through faster code for the runtime instrumentation.
> >
> > Topic 1 is going to be a static dataflow analysis as it was proposed by
> > Ondrej for the ECOOP/OOPSLA paper. So - as a coursework for Laurie's
> > compiler course - I would like to implement such an analysis in order to
> > speed up both, tracematches and J-LO. In fact I think the very same
> > analysis should apply to both tools - actually they should even apply to
> > any other approach in the field such as PQL, HAWK etc... Based on this
> > implementation we could then certainly try to publish something about
> > it. (Here we could in particular try to find out if this is also
> > applicable to context free stuff - which I actually think should be the
> > case.)
> >
> > So my question at the moment is just who of you would be interested in
> > getting involved with this, i.e. right now contribute some ideas, take
> > some time to think about the necessary analysis, probably cases which
> > might break those and so forth. Any volunteers?
> >
> > And probably I should mention that on the field of verification, I think
> > such an analysis would be a great contribution because it would in
> > combination with our tools lead to something very similar to Model
> > Checking, which has hardly ever been done (and never very efficiently
> > AFAIK) for full Java.
> >
> > Eric
> >
> > --
> > Eric Bodden
> > Sable Research Group, McGill University
> > Montreal, Canada
> >
> >
>
>
>
>
>
Received on Sat Jan 28 14:05:05 2006