Eric Bodden, Ph.D. Current conditions in Darmstadt: Cloud and Visibility OK, 11°C
11°C

Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
  • rss
  • Home
  • Research
    • Publications
    • Presentations
    • Current research
      • Join Point Interfaces
      • RefaFlex – Safer refactorings for reflective Java programs
      • Stateful Breakpoints
      • MOPBox
      • Closure Joinpoints for AspectJ
      • Proving Security Properties of Services
      • TamiFlex: a tool set for Taming Reflection
      • Clara: Compile-time Approximation of Runtime Analyses
    • Past Research
      • Efficient Runtime Verification
      • Racer: Effective Race Detection Using AspectJ
      • Continuation-equivalent states (ICSE 2010)
      • Aspect-oriented programming and design
      • Visual specification languages
      • A denial-of-service attack on the Java bytecode verifier
    • Hosting a Program Committee meeting with Skype
  • Tools
    • Behavior Compliance Control
    • Join Point Interfaces
    • TamiFlex: a tool set for Taming Reflection
    • Closure Joinpoints for AspectJ
    • Clara: Compile-time Approximation of Runtime Analyses
    • RacerAJ (for race detection)
    • An introduction to Soot 2.2.5
    • J-LO, a tool for runtime-checking temporal assertions
    • Aspect-oriented approaches targeting the .NET Framework
  • Teaching
    • Current lectures and thesis topics
    • Past lectures
      • Automated Software Engineering
      • Software-Engineering Project
      • COMP 520
      • COMP 621
  • About me
  • Photos

Packs and phases in Soot

Eric | November 26, 2008

This the fourth post in a series of blog posts about frequently asked questions with using Soot. Today’s topic will be on packs and phases in Soot.

One frequent question that comes up on the Soot mailing list is when to run a particular analysis in Soot. Soot’s execution is divided in a set of different packs and each pack contains different phases. Therefore the question could be rephrased as “In which pack do I have to run my analysis or transformation?”. This tutorial tries to help you answer this question.


jb: Jimple Body Creation

image

The diagram to the right shows you the different packs that exist in Soot. First, Soot applies the jb pack to every single method body, or in other terms to every method that has a body. Native methods such as System.currentTimeMillis() have no body. The jb pack is fixed and it is concerned with the creation of the Jimple representation. It cannot be changed!

Whole-program packs

Then Soot next applies four whole-program packs

  1. cg, the call graph pack,
  2. wjtp, the whole-jimple transformation pack,
  3. wjop, the whole-jimple optimization pack, and
  4. wjap, the whole-jimple annotation pack.

All of these packs can be changed, and in particular one can add SceneTransformers to these packs that conduct a whole-program analysis. A SceneTransformer accesses the program through the Scene in order to analyze and transform the program. This code snippet here adds a dummy transformer to the wjtp pack:

public static void main(String[] args) {
  PackManager.v().getPack("wjtp").add(
      new Transform("wjtp.myTransform", new SceneTransformer() {
        protected void internalTransform(String phaseName,
            Map options) {
          System.err.println(Scene.v().getApplicationClasses());
        }
      }));
  soot.Main.main(args);
}

(wait) Note though, that whole-program packs are not enabled by default. You have to state the -w option on Soot’s command line to enable them.

Jimple packs jtb, jop, jap

Similar to Soot’s whole-program packs, Soot then applies –again to each body– a sequence of three packs:

  1. jtp, the jimple transformation pack,
  2. jop, the jimple optimization pack, and
  3. jap, the jimple annotation pack.

jtp is empty and enabled by default. This is usually where you want to place your intra-procedural analyses.

jop comes pre-equipped with a set of Jimple optimizations. It is disabled by default and can be enabled by using Soot’s -o command line option, or by using the switch –p jop enabled.

jap is the annotation pack for Jimple. Here, annotations are added to each Jimple body that let you or others or a JVM assess the results of the optimizations. By default, this pack is enabled but all default phases in the pack are disabled. Hence, if you add your own analysis to this pack it will automatically be enabled by default.

The following code snippet enabled the null pointer tagger and registers a new BodyTransformer which prints out tags for each statement in every method:

public static void main(String[] args) {
  PackManager.v().getPack("jap").add(
      new Transform("jap.myTransform", new BodyTransformer() {

        protected void internalTransform(Body body, String phase, Map options) {
          for (Unit u : body.getUnits()) {
            System.out.println(u.getTags());
          }
        }

      }));
  Options.v().set_verbose(true);
  PhaseOptions.v().setPhaseOption("jap.npc", "on");
  soot.Main.main(args);
}

Note that every Transform added to a (non-whole) Jimple pack must be a BodyTransformer.

Packs bb and tag

As the diagram at the top shows, Soot next applied the packs bb and tag to each body. The bb pack converts the (optimized and tagged) Jimple bodies into Baf bodies. Baf is Soot’s stack based intermediate representation from which Soot creates bytecode. The tag pack last but not least aggregates certain tags. For instance, if multiple Jimple (or Baf) statements share the same line number tag then Soot will retain this tag only on the first instruction that carries this tag, to gain uniqueness.

The Dava body pack db

Since a little more than a year, Soot has an additional pack, db, not shown on the slide at the top. Its sole use is to enable or disable certain transformations when decompiling code into java using the –f dava command line option. It contains no actual transforms, and nothing should be added to it.

Which packs are enabled when?

One other big point confusion is always which packs are enabled when. The following two documents explain all the settings in question and their defaults:

  • Soot command line (watch out for the –W and –O options)

    –O will enable the packs bop, gop, jop and sop (i.e. sets e.g. –p jop enabled:true), –W enables wjop and wsop

  • Soot phase options (explains every single phase in every pack and its settings)

Related Posts

No related posts.

Categories
Research
Tags
LinkedIn, Soot, Soot Tutorial
Comments rss
Comments rss
Trackback
Trackback

« Von Atlanta, Hydranten mit Schildchen, und Mooseriegeln Collaborative Runtime Verification with Tracematches »

6 Responses to “Packs and phases in Soot”

  1. Amir Mehrabi says:
    January 8, 2009 at 9:29 am

    Hi
    I want to know how can i export Call Graph of whole program to a file like XML

    thank you

    Reply
    • eric says:
      January 9, 2009 at 5:03 am

      Hi Amir.

      I don’t think that there’s a ready-made class for this but you can easily do it yourself. Ondrej once posted some code that dumps it to a text file. See here…

      Reply
  2. Amir Mehrabi says:
    January 12, 2009 at 8:48 am

    Hi Eric
    Thanks for your reply
    I want to know how can I getting the CallGraph for a Method not for a scene?

    I write a class that extends BodyTransformer , I like to get CallGraph of a method in the internalTrasforme(Body body,….)

    thanks

    Reply
    • eric says:
      January 20, 2009 at 9:17 am

      That’s quite easy. Either (1) you just get the whole-program call graph from the scene and then query the outgoing edges of this graph for the method that you are interested in, or (2) you simply inspect all invoke statements in the method manually to see what may be called.

      Reply
  3. iirekm says:
    January 4, 2011 at 9:21 am

    Hello,
    I see that recent 1.6 HotSpot JVMs do quite a lot optimizations by themselves, so Soot doesn’t help too much now as it could a few years ago.
    But I noticed that the biggest performance problem with recent JVMs for me is lack of object inlining (boxing of primitive types for example); creating millions of Doubles really costs a lot.

    Does Soot, or some other generally-available optimizer for Java support object inlining?

    Reply
    • Eric says:
      January 4, 2011 at 10:02 am

      Hello.

      You observation about the modern JITs is certainly correct. About Object Inlining: No, I am not aware of such an optimization. The problem with such an approach may be that most of the time programmers are aware of the performance impact of using objects to represent primitive values and therefore they only do so if they have to, e.g. when storing primitive values in hash maps. In this case, the problem is rather in the data structures and type system than in the program itself and therefore there is little or no optimization potential. But this is just my theory and it may still be worth to investigate this on actual programs.

      Eric

      Reply

Leave a Reply

Click here to cancel reply.

Welcome

Welcome to my website. Interested in my research? Click here for details or jump directly to my publications.

Upcoming Conferences

Photos

Categories & Feeds

  • Research
    RSS
    (141)
  • Misc
    RSS
    (97)
  • Montreal
    RSS
    (44)

Collaborations

  • Don Batory, UTA
  • Eric Tanter, Universidad de Chile
  • Friedrich Steimann, Fernuni Hagen
  • Grigore Rosu, UIUC
  • Hans Vangheluwe, McGill University/Universiteit Antwerpen
  • Klaus Havelund, NASA JPL
  • Laurie Hendren, McGill University
  • Matthew Dwyer, University of Nebraska
  • Oege de Moor, University of Oxford
  • Ondrej Lhotak, University of Waterloo
  • Patrick Lam, University of Waterloo
  • Sarfraz Khurshid, UTA
  • Shahar Maoz, RWTH Aachen
  • Tian Zhao, UW Milwaukee
  • Volker Stolz, University of Oslo

Research projects

  • AspectBench Compiler (abc)
  • Clara
  • J-LO
  • Soot
  • Stratified aspects
  • TamiFlex

Service

  • AOSD 2006
  • AOSD 2007
  • AOSD 2010
  • AOSD 2011
  • AOSD 2012
  • ATVA 2008
  • ECOOP 2008 Doctoral Symposium
  • ECOOP 2010
  • ESEC/FSE 2011 New Ideas Track
  • FOAL 2010
  • FOAL 2012
  • ICSE 2010
  • ICSE 2013 (New Ideas)
  • IEEE Transactions on Software Engineering (TSE)
  • International Journal of Image and Graphics
  • ISSTA 2011
  • NFM 2011
  • OOPSLA 2008
  • OOPSLA 2010
  • OOPSLA 2012
  • PEPM 2008
  • PLDI 2006
  • PLDI 2008
  • RAM-SE 2011
  • RV 2007
  • RV 2009
  • RV 2010
  • RV 2011
  • SAC 2012
  • SC 2011
  • SEFM 2005
  • SEFM 2008
  • Transactions on Software Engineering and Methodology (TOSEM)
  • VMIL 2008
  • VMIL 2009

Some other people I know

  • Adrian Colyer
  • Bruno Dufour
  • Dan North
  • Daniel Klink
  • Dave Thomas
  • Dean Wampler
  • Eric Tanter
  • Friedrich Steimann
  • Joachim Kneis
  • Klaus Havelund
  • Liz Keogh
  • Malte Clasen
  • Markus Schorn
  • Pascal Costanza
  • Patricia Jablonski
  • Philip Mayer
  • Ron Bodkin
  • Sven Wittig
  • Wiebke Berg

Some people not to confuse me with

  • Eric B. the terrorist
  • Eric Bodden the basketball player
  • Eric Bodden the chef who sunk
  • Master Sgt. Eric Bodden

Previous Posts

November 2008
M T W T F S S
« Oct   Dec »
 12
3456789
10111213141516
17181920212223
24252627282930

Tags

Alumni AOP AOSD AspectJ Atlanta Bike Blizzard Bug finding Caro Clara COMP 621 Eclipse FSE Google ISSTA Java LinkedIn Mac McGill Microsoft Montreal NASA Photos Programming Quebec City Race detection Racer Runtime Monitoring Runtime verification RV RWTH Seattle Slides Snow storm Soot Soot Tutorial Static Analysis Strike TamiFlex TA strike Thesis tracematches Typestate Vacation Winter carnival


rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox