Re: Limiting whole-program analysis

[Ondrej Lhotak <olhotak@sable.mcgill.ca>]

On Thu, Jun 03, 2004 at 04:41:48PM +0200, Helge Jensen wrote:
> 
> 
> Ondrej Lhotak wrote:
> 
> > On Thu, Jun 03, 2004 at 09:51:45AM +0200, Helge Jensen wrote:
> 
> First of all, thanks for you elaborate explanation and your interest. It 
> is valued.

You're welcome!

> > If you want the analysis to still be conservative, simple things break
> > down.
> 
> That's OK. if I can just state which behaviour will result in breakdown.
> 
> When I have the simple things working, I can begin considering what to 
> do about the advanced things (like exceptions, threads, ...). Untill 
> then I really just want the analysis to complete fast, even if that 
> limits the set of valid inputs, so I can actually get some work done :)
> 
> For figuring out which options I needed to pass to soot to generate the 
> right amount of points-to information for my purposes, what the 
> different output-formats looked like, what dava was and so on, I must 
> have run soot >50 times on a small example program. Then it makes a 
> _lot_ of difference if it completes in 2 seconds or 2 minutes :)

Two other switches to consider are -p cg
safe-forname:false,safe-newinstance:false. On my machine, they speed
things up by a factor of 5 with the 1.4 class library. The default is
to assume that any calls to Class.forName() and Class.newInstance()
that cannot be proven to refer to a specific class might refer to all
classes. Getting rid of this conservative assumption makes the call
graph much smaller. (It has much less of an effect with the 1.1 library
because it doesn't use these reflection facilities as much, if at all).

> Thats a nice topic, and I would like to do some work on that... when my 
> thesis is complete :)

Same here...

Ondrej

> 
> -- 
> Helge
>