[Soot-list] global side-effect analysis with soot?

Chris Pickett chris.pickett at mail.mcgill.ca
Tue Aug 9 08:45:12 EDT 2005


Hi Christian,

It sounds like you want something very similar to a purity analysis. 
You should see both the paper [1] and technical report [2] on purity 
analysis by Alexandru Salcianu and Martin Rinard.  Antoine Mine, a 
visitor to the Sable lab, started work on implementing this in Soot last 
February, although his code remains untouched, and you would need to 
finish things up.  You'll find the relevant files in the Soot trunk if 
you grep for purity ($ grep -ilr purity src/).  Also, I think Alex's 
implementation of this analysis in FLEX is available if you want it, 
either for understanding what you need to do in Soot, or if you just 
want to use it as is.  If you want some space to work on it in the Soot 
repository, let us know, and we can arrange for a sandbox.

Cheers,
Chris

[1] Alexandru Salcianu and Martin Rinard.  Purity and Side Effect 
Analysis for Java Programs.  Proceedings of the 6th International 
Conference on Verification, Model Checking and Abstract Interpretation 
(VMCAI'05), Paris, France, January 2005.

[2] Alexandru Salcianu and Martin Rinard.  A Combined Pointer and Purity 
Analysis for Java Programs.  Technical Report MIT-CSAIL-TR-949, MIT, 
Cambridge, Massachusetts, May 2004.

Christian Lindig wrote:
> I am new to Soot and would be grateful for advice whether the following 
> could be implemented with Soot: we like to identify all observer methods 
> for a number of classes. Such a method returns an object but otherwise 
> does not create objects that outlive its invocation or mutates any 
> existing object.
> 
> For this we need a global data flow analysis that marks methods as 
> observer or mutator. Because of dynamic binding we have to be 
> conservative and have to analyze all methods that could potentially be 
> invoked; a similar problem pose calls against an interface where we have 
> to know all implementations of that interface. Because of cyclic 
> dependencies such an analysis must reach a fix point.
> 
> In any case, I suspect that the Soot framework will be helpful but would 
> be grateful for your opinion and what part of Soot would be most useful.
> 
> -- Christian
> -- 
> http://www.st.cs.uni-sb.de/~lindig/
> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> 




More information about the Soot-list mailing list