RE: Call Graph construction overhead

[Eric Bodden <eric@bodden.de>]

owner-soot-list@sable.mcgill.ca <> wrote:

> If you are interested in an incomplete call graph, you need
> to somehow specify in what way it should be incomplete, and
> this would depend on your application. So, before
> implementing a generic solution, we would need to agree on a
> way to specify the incompleteness.
I think one approach that is useful quite often is to just not allow any
edges that go through certain Classes / packages (like e.g. java.*). 
 
> I'm open to suggestions. I'd also like to hear about the
> kinds of applications you're thinking of for which an
> incomplete call graph would be acceptable. My experience is
> mostly with analyses requiring a conservative one.
I totally agree that for automated optimizations etc. this does not make
much sense. However it does make sense for program analysis, e.g. call graph
/control flow visualization. In that case people often are not interested in
what happens in the JRE etc. One problem I see with that approach however
relates to callbacks: If somebody invokes some filtered object that calls
back a non-filtered one (e.g. a call to List.sort(), that will call back to
compareTo(...) of its elements), this call-back will not be captured in such
a graph. Similar problems relate to subclasses of filtered classes etc. Not
quite trivial indeed. However I am seeing a high and still increasing demand
for this and probably this list is not thee worst place for discussion.

Eric

-- 
Eric Bodden
RWTH Aachen University
ICQ UIN: 12656220
Website: http://www.bodden.de
PGP key: http://www.bodden.de/pub_key.asc