Re: Aggregating/annotating call graphs

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

In order to be as general as possible (to provide the most information),
the call graph consists of edges from call sites to target methods. If
you need them aggregated by source method or whatever other attribute,
you need to aggregate them yourself. If you come up with a generic
aggregation tool, it may be of use to other Soot users, and we would
probably include it in Soot if you contributed it.

Ondrej

On Fri, Aug 22, 2003 at 08:22:39AM +0100, Eric Bodden wrote:
> Hi!
> 
> Yesterday I generated one of the really poor "Application classes only" call
> graphs and was surprised to see, that if I had methods with multiple calls
> to another method these edges appeared also multiple times. I always thought
> that this woud already be optimized away in CHA. But actually that's not a
> bad thing because what I really would like to get are aggreagated edges,
> labeled with an intereg, that tells me how many ancestors (before
> aggregation) existed. So if I have n such "redundant" edges, this would fold
> to one edge. labeled with n. That would in general tell one in a
> straightforward way what the degree of coupling between two methods is.
> So basically two questions: Does "real SPARK" usually optimize away such
> redundant edges? If not, is it available as an option? Secondly: Is the
> feature described above (labeling) alreay somehow implemented; if not, do
> you think it would be worthwhile having such an operation  "on the call
> graph" or should I probably better aggregate the output (by tweaking the
> lists, the iterators provide me)? I guess the latter would be way easier,
> though the former could probably have applications in other parts of SOOT.
> 
> An extension of that would probably be, to aggregate further over whole
> classes and probably even packages (though that should not be done on the
> call graph itself, I propose) to report, how tight classes respectively
> packages are coupled. Of course this whole information is not very useful
> for the actual purpose of SOOT, being an optimization framework. But for
> what I am using SOOT - as base to a high level visualization tool - it would
> be great to have such statistics.
> 
> Thank you very much,
> Eric
>