Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Whole program Devirtualization Optimizations
This note explains how to use call graph information for whole-program devirtualization optimizations. The user should first be familiar with material in both Soot command-line options and Phase options.
Running whole-program optimizations
Soot provides tools for whole-program optimizations in the
wjop pack. To use these tools, one must run soot in whole-program mode and must have turned on optimization. This is accomplished by the command-line option
-W. Since we want Soot to output all the classes in our application, we should also use the
The wjop pack contains two transformers,
StaticInliner. Only one transformer should be applied for each execution. By default,
StaticMethodBinder is disabled and
StaticInliner enabled. This can be changed by setting the enabled option for each transformer.
wjop.si) does the following:
- finds call sites which are monomorphic (i.e. has only one target);
- checks whether the call sites can be safely inlined. The inlining criteria are listed in Vijay Sundaresan's Master's thesis;
- if the call site is safe to inline, inlines the body of the target into that of the caller.
wjop.smb) does the following:
- finds call sites which are monomorphic;
- creates an new static method which has a body identical to the target, but whose first parameter is the object that used to be the receiver;
- redirects the original call site to the newly-created static method.
By default, the call graph is build using CHA. Spark can be used instead by enabling it with the option
-p cg.spark on. Spark can also simulate other analyses such as VTA (
-p cg.spark vta) or RTA (
-p cg.spark rta).
Including dynamically-loaded classes
If the program to be optimized loads classes dynamically using the
newInstance method, Soot will be unable to tell statically which classes need to be resolved. In this case, the user will need to tell Soot explicitly which classes are loaded. This can be done using one of the following command-line options:
--dynamic-dirlets the user specify paths under which all classes are considered potentially dynamic.
--dynamic-packagelets the user specify packages for which all class files belonging to the package or any subpackage thereof are considered potentially dynamic. For instance, saying
--dynamic-package sun.security.providerwill mark a class like
sun.security.provider.Provideras potentially dynamic.
--dynamic-classlets the user specify specific dynamic classes.
These options may be specified multiple times to specify multiple dynamic directories, packages, or classes. Note: The user must specify all potentially dynamic classes using one (or both) of the above, or the call graph may be incomplete.
java -Xmx4g soot.Main --app -W -p wjop.smb on -p wjop.si off spec.benchmarks._201_compress.Main
This command runs
StaticMethodBinder instead of
StaticInliner. It does not include any dynamic packages. The
-Xmx4g switch is present so that the virtual machine is allowed to use more memory (4 Gb) than the default value (since whole-program analysis usually uses a lot of memory). Note that the switch for allowing more memory usage may be different depending on the virtual machine used.
java -Xmx4g soot.Main --app -W --dynamic-package java.text.resources --dynamic-package spec.benchmarks._213_javac SpecApplication
This command runs
StaticInliner. It uses CHA to find monomorphic sites. It analyzes library classes, and it includes all classes in the packages
java.text.resources, spec.benchmarks._213_javac, or any of their subpackages, as potentially dynamic classes. It allows the virtual machine to use 4 Gb of memory.