DaCapo 9.12 "bach"
The "bach" release of DaCapo uses a non-trivial class-loading mechanism
and reflection to bootstrap each benchmark for which the harness is
invoked. Static analysis of DaCapo therefore requires static-analysis
tools to (1) obtain access to all classes that are loaded at runtime,
and (2) obtain information about all reflective calls. Eric Bodden now provides the TamiFlex tool
that allows you to gather both class files and a reflection log file. Soot
2.4.0 and later can use the
reflection log file to fully statically analyze the DaCapo "bach"
release. See this
Technical Report for details.
This page
explains in detail how to analyze
DaCapo "bach" with Soot.
Deprecated: DaCapo 2006-10
The remainder of this page describes how to use the 'xdeps' packaging
of the old (out of date) 2006-10 release of the DaCapo benchmark suite
(eg dacapo-2006-10-MR2-xdeps.zip) to process them with Soot. The
information may be of interest to anyone performing ahead-of-time
whole program analyses.
Please note that we strongly recommend that you use the
regular jar packaging of the suite (eg dacapo-2006-10-MR2.jar)
unless you specifically need to use the 'xdeps' repackaging as
described here.
Special thanks to Eric Bodden of McGill for helping develop support
for Soot and contributing the following.
Processing the DaCapo benchmarks with Soot
The DaCapo benchmarks can be fully processed with Soot. (The following was
tested with Soot version 2.2.3.)
About stub classes
One problem that arose early on when trying to conduct a whole-program
analysis on the DaCapo benchmarks is that DaCapo uses reflection to
bootstrap its Harness, obscuring the static path to the benchmark.
Therefore, DaCapo now includes a stub class for bootstrapping static
whole-program analyses, which "appears to call" the harness directly.
(We invoke the respective methods with fake arguments). This should
work for most analyses, however there might be occasions where one
needs to tamper around with them. If so, feel free to do so - they are
contained in the source distribution as well. Those stub classes adhere
to the name pattern dacapo.<bm>.Main.
Application classes and library classes
Soot users are probably aware that Soot distinguishes between
application classes and library classes (only the former are optimized,
see the Soot
tutorial for details). In order to support this model, there is an
"xdeps" packaging of DaCapo available, where each benchmark, bm,
is compiled separately into two jars. One file has the name <bm>.jar
and holds all application classes for the benchmark bm. The
other file has the name <benchmark>-deps.jar and holds
all library classes for the benchmark. This packaging is avaliable as a
binary download (dacapo-<RELEASE>-xdeps.zip), or via an
ant target for a source build.
Applying Soot to the DaCapo benchmarks
In order to apply Soot to a benchmark BM you basically need
the following command line (or you can use the following script):
java -Xmx512m -cp ./abc-complete.jar \
soot.Main \
-process-dir ${TEMP} \
-soot-class-path ${JRE}/lib/rt.jar:${JRE}/lib/jce.jar:${JRE}/lib/jsse.jar:${B}-deps.jar:${TEMP} \
-main-class dacapo.${BM}.Main \
${CUSTOM_OPTIONS}
Here, TEMP points to some temporary directory, JRE
to the Java runtime library you want to analyze and BM to the
name of one of the DaCapo benchmarks.
In case of any questions, feel free to email Eric Bodden.