Re: [abc] Dataflow analysis

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 10:11:58 2006