As a user of the SootUp framework, you can omit these topics which mostly explain how some of the concepts work internally.
+Soot Equivalent
+ +Almost in all use-cases you can simply ignore body interceptors. They are applied to each Body by default to create their rather normalized or leaner versions, e.g.
+by eliminating unreachable code (UnreachableCodeEliminator), standardizing names of locals (LocalNameStandardizer), or removing empty switch statements (EmptySwitchEliminator) etc.
Below, we show how these body interceptors work for the users who are interested in their internal workings.
+LocalSplitter is aBodyInterceptorthat attempts to identify and separate uses of a local variable (as definition) that are independent of each other by renaming local variables.
Example 1:
+
As shown in the example above, the local variablel1is defined twice. It can be split up into two new local variables: l1#1 and l1#2 because the both definitions are independent of each other.
Look for foldable navigation and tabs for showing old vs new
+Example 2:
+
In the second example, the local variablel2is defined thrice. But it cannot be split up into three new local variables as in the first example, because its definitions in the if-branches are not independent of each other. Therefore, it can only be split up into two local variables as shown in the figure.
LocalPacker is aBodyInterceptorthat attempts to minimize the number of local variables which are used in body by reusing them, when it is possible. It corresponds to the inverse body transformation of LocalSplitter. Note: Every local variable's type should be assigned before running LocalPacker.
Example:
+
In the given example above, the local variablesl1,l3are summarized to be one local variablel1, because they have the same type without interference with each other. Likewise, the local variablesl2,l4andl5are summarized to be another local variablel2. Although the local variablel0doesn't interfere any other local variables, it cannot be summed up with other local variables because of its distinctive type.
TrapTightener is aBodyInterceptorthat shrinks the protected area covered by each Trap in a Body.
Example:
+
We assume in the example above that only theStmt:l2 := 2might throw an exception caught by theTrapwhich is labeled withlabel3. In the jimple body before running the TrapTightener, the protected area covered by the Trap contains threeStmts:l1 := 1; l2 := 2; l2 := 3. But an exception could only arise at theStmt:l2 := 2. After the implementation of TrapTightener, we will get a contractible protected area which contains only theStmtthat might throw an exception, namely theStmt:l2 := 2.
EmptySwitchEliminator is aBodyInterceptorthat removes empty switch statements which contain only the default case.
Example:
+
As shown in the example above, the switch statement in the jimple body always takes the default action. After running EmptySwitchEliminator, the switch statement is replaced with aGotoStmtto the default case.
UnreachableCodeEliminator is aBodyInterceptorthat removes all unreachable statements.
Example:
+
Obviously, the code segmentl2 = 2; l3 = 3;is unreachable. It will be removed after running the UreachableCodeEliminator.
CopyPropagator is aBodyInterceptorthat supports the global copy propagation and constant propagation.
Example for global copy propagation:
+
Consider a code segment in the following form:
+1 +2 +3 | |
According to the copy propagation's definition, the statementc = use(a)can be replaced withc = use(b)iff both conditions are met:
ais defined only one time on all the paths froma = btoc = use(a).bon any path froma = btoc = use(a).In the example for global copy propagation, the first usedl1is replaced withl0, but the second usedl1cannot be replaced withl3, because the second condition is not satisfied.
Example for constant propagation:
+
Constant propagation is similar to copy propagation. Consider a code segment in the following form:
+1 +2 +3 | |
After perfoming the constant propagation, the statementb = use(a)can be replaced withb = use(const)iffais not redefined on any of the paths froma = consttob = use(a).
Therefore, the first usedl1in the second example can be replaced with the constant1, but the second usedl1cannot be replaced with the constant2, becausel1is redefined on the path froml1 = 2tol4 = use(l1). However, it can be replaced with local variablel2, because the both conditions of copy propagation are met.
LocalNameStandardizer is aBodyInterceptorthat assigns a generic name to each local variable. Firstly, it will sort the local variables' order alphabetically by the string representation of their type. If there are two local variables with the same type, then the LocalNameStandardizer will use the sequence of their occurrence in jimple body to determine their order. Each assigned name consists of two parts:
The following table shows the letter corresponding to each type:
+| Type of Local Variable | +Letter | +
|---|---|
| boolean | +z | +
| byte | +b | +
| short | +s | +
| int | +i | +
| long | +l | +
| float | +f | +
| double | +d | +
| char | +c | +
| null | +n | +
| unknown | +e | +
| reference | +r | +
StaticSingleAssignmentFormer is aBodyInterceptorthat transforms jimple body into SSA form, so that each local variable is assigned exactly once and defined before its first use.
Example:
+
In the given example, the StaticSingleAssignmentFormer assigns eachIdentityStmtandAssignStmtto a new local variable . And each use uses the local variable which is most recently defined. Sometimes, it is impossible to determine the most recently defined local variable for a use in a join block. In this case, the StaticSingleAssignmentFormer will insert aPhiStmtin the front of the join block to merge all most recently defined local variables and assign them a new local variable.
LocalLivenessAnalyser is used for querying for the list of live local variables before and after a given Stmt.
Example:
+
The live local variables before and after each Stmt will be calculated after generating an instance of LocalLivenessAnalyser as shown the example above. They can be queried by using the methods getLiveLocalsBeforeStmt and getLiveLocalsAfterStmt.
DomianceFinder is used for querying for the immediate dominator and dominance frontiers for a given basic block.
+Example: 
After generating an instance of DominanceFinder for a BlockGraph, we will get the immediate dominator and dominance frontiers for each basic block. The both properties can be queried by using the methodsgetImmediateDominatorandgetDominanceFrontiers.
We would like to announce Soot’s successor, SootUp.
+Over more than 20 years, Soot has become one of the world’s most popular academic tool for Java and Android analysis and instrumentation. We thank all of you who have used and contributed to it over the years! It was your feedback and your contributions that helped it grow into such a versatile tool!
+However, over the years, the requirements for Soot have changed a lot, and given its original architecture, it was no longer quite up to the task. Soot was originally developed for ahead-of-time code transformation, particularly optimization, which has become very uncommon in Java. Current use cases center much more around powerful program analyses and program-understanding tasks.
+Today we are officially releasing SootUp, a new version of Soot with a completely overhauled architecture. With SootUp, we aim to keep the best things about Soot, yet overcome a lot of its drawbacks. We very much restructured Soot, particularly abolishing the heavy use of singletons. Soot now has a concept of views; each view corresponds to some version or variant of an analyzed program, and multiple views can be kept in memory at the same time. This sets the foundation, for instance, for differential or incremental program analyses.
+SootUp is a library that can easily be included in other projects, leaving those projects in control. For those who intend to use it as a framework, with inversion of control, SootUp provides additional templates that help you and novices to get started more easily. The Jimple IR has been slightly simplified, and has been made immutable by default such that internally SootUp can make use of caching where desired. Where required, Jimple transformations are still allowed, but in a systematic manner, for instance assuring that analyses depending on the transformed code are notified about its changes.
+Below is an overview of what’s new.
+SootUp is not a drop-in replacement for Soot! Due to its completely new architecture and API it is essentially an almost complete rewrite. For a while, Soot and SootUp will coexist, as many existing tools depend on Soot, yet our maintenance efforts will henceforth be focused on SootUp, not Soot, and on extending SootUp with those capabilities that people still find missing. For now, we recommend using SootUp for greenfield projects.
+For more details, check out +* The SootUp home page: https://soot-oss.github.io/SootUp/, and +* The SootUp repository: https://github.com/soot-oss/SootUp/
+We are very much looking forward to your feedback and feature requests. To this end, best create appropriate issues in the repository.
+This major upgrade of Soot was made possible by generous competitive funding by the DFG, within the project “Future-proofing the Soot Framework for Program Analysis +and Transformation (FutureSoot)”. It was funded in the DFG’s program on Research Software Sustainability.
+ + + + + + +