[Soot-list] Call Graph Performance and Alternatives

[Kyle Patrick Holohan]

We are having serious performance issues when attempting to generate a
call graph with Soot. When invoking Soot on a small hangman
application with a GUI, the following output is produced:

Soot started on Wed Sep 29 15:30:22 MST 2010
No main class given. Inferred 'testclasses.hangman.HangManClient' as main class.
[Call Graph] For information on where the call graph may be
incomplete, use the verbose option to the cg phase.

We have added a custom scene transform to the wjtp pack, which runs
after the code has been turned into jimple and the call graph has been
generated; however, after invoking soot and before execution reaches
our custom scene transformer, Soot seems to be using between 1 and 2
GB of memory and 100% of one core CPU time for 1.5 - 2 minutes
producing only the above output. More complex applications throw an
out of memory exception, even when tested on a large maximum heap
size.

Our application relies on the call graph to determine method
dependencies. Is this behavior expected of Soot? Are there any present
workarounds?  Does Soot also generate a call graph of the java.* and
javax.* packages if they are referenced by an input class, and if so,
is there any way to change this behavior? For the purposes of our
application, it may not be necessary to have a call graph that
includes classes from the Java framework.

We are currently considering the following options:
- Modifying the Soot source to exclude java.* and javax.* classes from
call graph construction,
- Implementing a custom call graph generation library for the application, and
- Modifying the Soot source to remove unused call graph attributes to
try to cut down on overall memory usage.

Any other suggestions would be extremely helpful. Thanks in advance.

-- 
Kyle Holohan
Undergraduate; Department of Computer Science
The University of Arizona