[Soot-list] Multiple instances of Soot in a single host program

[Steven Arzt]

Hi Wei,

 

Soot was sadly never intended to support such use cases. We have issues with those design decisions (that date back more than ten years) in our own projects as well. The best workaround we have found so far is to quick-switch between Soot instances. We create one copy of all singletons, then reset Soot, load the next instance, save it again, etc. Whenever a thread needs to access one of the singletons, we check which thread it is, get the corresponding saved generic instances, and restore them. This means that we cannot have real concurrency, but we can simulate the singletons for every thread by copying back and forth. Support for this switching has been added to the G class (look for “GlobalObjectGetter”).

 

I know that this is not a real solution, but changing such low-level design decisions is almost impossible in a project like Soot without breaking almost all  current applications that use Soot.

 

Best regards,

  Steven

 

Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Wei Peng
Gesendet: Freitag, 26. Dezember 2014 23:18
An: soot-list at CS.McGill.CA
Betreff: [Soot-list] Multiple instances of Soot in a single host program

 

Hi,

 

First, thanks for open sourcing Soot and keeping on making it better after so many years.

 

I have searched but not found any answer to my following question.

 

It appears to me that Soot is designed to be Singleton, evidenced by the ubiquitous .v() calls for retrieving the root objects (Scene, Main, etc). However, if I want to do separate analyses on totally different set of classes in a single host program, the global states shared by Singleton would interfere with each other.

 

My questions are: 

* How can I host multiple instances of Soot in a single program? 

* If it is not possible without making intrusive changes to Soot, can I somehow reset the global state?

 

What I have found that maybe relevant:

* G.v().reset()

 

Use case I have a host program that uses Soot to construct SootMethod/SootClass, on which the host program will extract info. The host program takes a bunch of Android APK names from STDIN, and farms out isolated analyses of the APKs to a pool of worker threads. One step in these worker threads is to use Soot to construct SootMethod of the APK (using the "jb" pack). However, the Singleton architecture of Soot would prevent me from doing this.

 

Motivation All the benefits of using a single JVM to do multiple tasks: Saving JVM start time, using lightweight theads instead of OS processes, cache warming, control parallelism through FixedThreadPool instead of using GNU Make "-j" trick, etc.

 

Wei.

 

Wei Peng
Department of Computer and Information Science
Indiana University-Purdue University, Indianapolis (IUPUI)
pengw at iupui.edu  |  www.cs.iupui.edu/~pengw/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20141227/1932d942/attachment-0001.html