Advanced Topics
As a user of the SootUp framework, you can omit these topics which mostly explain how some of the concepts work internally.
Body Interceptors
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
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
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
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
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
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
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).- There are no definitions of
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
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:
- A letter to imply the local variable's type
- A digit to imply the local variable's order
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
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.
Tools
LocalLivenessAnalyser
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.
DominanceFinder
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.