Re: Limiting whole-program analysis

[Helge Jensen <jensen@slog.dk>]

Ondrej Lhotak wrote:

> Yes, these are consistent with what I'm seeing.

Ouch...

Tracing the ResolveMethod.addMethod, I can see that more than 14000 
methods are entered into the call-graph of the program:

  public class A { public static void main(String[] a) {} };

So that would explain why it takes so long.

> I tend to run Spark with the class library from the 1.3.1 JDK, which in
> this case ends up running about 6 times faster. I'm not quite sure what
> it is about the 1.4 class library that takes so long.

The 14000 methods are on the 1.4 class libs, i'll try out the 1.3.1 and 
make a count again.

I'm aiming at analyzing the points-to sets and call-graphs for just a 
few classes, and (at least in the edit/compile/debug/test cycle) 2 mins. 
is a long time to wait for something seemingly that simple.

Is there a way where i can reliably limit the visited graph, in a 
consistent manner? So as to say "it's faster, but it may disregard 
class-constructors and methods in the java.** packages".

For example by (ordered by expected simplicity):

  1. Reducing the precision of the analysis, by preventing it from 
visiting method-calls, class-constructors, serialization, ...
  2. Tranforming the CFG, replacing virtualinvoke for some places with 
"NOOP"

Note, that the "possible bug" i reported occurs only when i prevent 
ReachableMethods.addMethod from invoking reachable.add(m) for ALL m. So 
that solutions doesn't seem to work.

--
Helge