Re: Limiting whole-program analysis

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

On Thu, Jun 03, 2004 at 10:53:50AM +0200, Helge Jensen wrote:
> 
> 
> Helge Jensen wrote:
> 
> 
> >   1. Reducing the precision of the analysis, by preventing it from 
> > visiting method-calls, class-constructors, serialization, ...
> 
> After a bit of debugging, i found EntryPoints.java, and uncommented the 
> ret.addAll(implicit).
> 
>      public List all() {
>          List ret = new ArrayList();
>          ret.addAll( application() );
>        	//ret.addAll( implicit() );
>          return ret;
>      }
> 
> Now, it seems the analysis is pretty much restricted to what i want, and 
> finishes in seconds :)
> 
> With this disabled, which programs would yield inconsistent analysis 
> results? can it be summed up as programs that uses specific features of 
> the java language/runtime-system?

Well, even for Hello World, you'll get a call graph which excludes
things that are executed at run-time. However, particularly for
debugging, I'd guess most of your results would be close enough to
conservative. The things I can think of that you'd be ignoring are
class loading altogether, privileged actions, finalization, reflection,
threads.

Out of curiosity, how many methods are reachable if you remove the
implicit()? It would useful to see which specific methods in implicit()
cause your call graph to become unbearably large.

Anyway, for some of our applications, it was necessary to have a call
graph that is absolutely complete, so there was a lot of effort put into
ensuring that in Spark. Completeness was a higher priority than having a
very small call graph by ignoring unlikely but possible things. 

Ondrej

> I'm guessing programs that uses:
> 
>    - dynamic class-loading
>    - privileged actions
>    - finalization
> 
> Am i (just remotely) on the right track here.
> 
> -- 
> Helge
>