[Soot-list] Callgraph generation with Paddle

[François GOICHON]

Dear all,

I want to (at least I have to..) implement a crafted points-to analysis 
for Java components. I actually have to implement a different points-to 
sets propagation algorithm.
Therefore, I try to build a context-sensitive callgraph with Paddle, 
then I'll try to iterate over it or at least over the points-to sets to 
do my own stuff. I have been trying for some time now to construct a 
callgraph with Paddle, but I don't think I am doing it the right way so 
I am getting to you..

I am using what I understood from the survivor guide for now:

    private static SootClass loadClass(String name, boolean main) {
        SootClass sClass = Scene.v().loadClassAndSupport(name);
        sClass.setApplicationClass();
        if (main) {
            Scene.v().setMainClass(sClass);
        }
        return sClass;
    }

    private static void main(String[] args) {
       Options.v().set_keep_line_number(true);
       Options.v().setPhaseOption("cg", "verbose:true");
       Options.v().set_full_resolver(true);
       Options.v().allow_phantom_refs();

       loadClass("DummyClass",false);
       loadClass("MainClass",true);

       Scene.v().loadNecessaryClasses();

       // setting options HashMap

       PaddleTransformer pt = new PaddleTransformer();
       PaddleOptions paddle_opt = new PaddleOptions(opt);
       pt.setup(paddle_opt);
       pt.solve(paddle_opt);
       //Verifying Scene.v().getContextSensitiveCallGraph();

 }

For this first run I tried with a simple options hashmap, quite the same 
that the one in the survivor guide (1cfa, on the fly callgraph, no heap 
abstract with buddy as bdd lib).
DummyClass is quite simple (5 lines) and has only two imports: ArrayList 
and Iterator from java.util. The MainClass just calls a DummyClass 
object's method.

Because of the apparent simplicity of this application, I am astonished 
that there are roughly 2150 classes loaded in the Soot Scene, doesn't it 
seem a lot ? Anyway, I start the analysis, which takes some minutes and 
terminates with a segfault inside libjeddbuddy (during pt.solve()), 
because I am running out of memory I suppose. I provided -Xmx512m 
-Xss256m as vm arguments.
So my questions are:
 - is it possible not to load all this classes, most of them being 
certainly loaded from unrealizable paths for my application (I actually 
tried not to use the full resolver option but then I add to add hundreds 
of addBasicClass(..., SIGNATURE|BODIES) and it was giving the same 
result anyway) ? Or to let Paddle dynamically load the needed classes 
when it encounters them ?
- do I really need more memory for such a small program ??
 - is there an easier way to build a context-sensitive callgraph with 
paddle (I am actually not sure what is going on within 
PaddleScene.solve()) ?
I tried some different solutions from different existing applications 
using paddle without success.. I am quite lost and any hint or remark 
would be of great help for me.
Thanks,

François Goichon