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.