This is a re-post from my previous website. Posting as it may still be of use to research students treating the murky path of JVM research…
Update 26/05/2015. Thanks to Peter Hofer at JKU for a useful addendum regarding further problems!
Recently I’ve been doing some unusual memory management research using AspectJ. As part of this research, I’ve had to recompile the DaCapo 9.12 Benchmark Suite, which is the standard suite in memory management research.
In this post, I’ll explain how to do this. I built the suite on an Ubuntu 12.04, both 32-bit and 64-bit.
For the changes to files within the DaCapo file structure, I have created a patch for 64-bit compilation.
The first thing you’ll need to do is install three different versions of the Java SDK: 1.4, 1.5, and 1.6
These are available from the Oracle download archive:
The versions I installed were:
If you have any problems installing the 64-bit versions, try using the 32-bit equivalent after installing ia32-libs using apt-get.
Assuming they’re in your ~/Downloads folder:
cd ~/Downloads chmod +x j2sdk-1_4_2_19-linux-i586.bin jdk-1_5_0_22-linux-i586.bin jdk-6u45-linux-i586.bin
Then, one-by-one, run the scripts and agree to the license agreement:
./j2sdk-1_4_2_19-linux-i586.bin ./jdk-1_5_0_22-linux-i586.bin ./jdk-6u45-linux-i586.bin
The self-extracting binaries will have created subdirectories. These need to be moved:
sudo cp -r j2sdk1.4.2_19/ jdk1.5.0_22/ jdk1.6.0_45/ /usr/lib/jvm
Now configure the java installs using update-alternatives:
sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/j2sdk1.4.2_19/bin/java" 1 sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.5.0_22/bin/java" 2 sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.6.0_45/bin/java" 3 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/j2sdk1.4.2_19/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.5.0_22/bin/javac" 2 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.6.0_45/bin/javac" 3
Note that you must have version 6 set as your default to compile the benchmarks, at least at the moment you initiate the build:
Installing Other Packages
You’ll want to install apache ant, subversion, cvs, javacc:
sudo apt-get install ant subversion cvs javacc
Downloading the DaCapo Source
Change to the directory you want to work within.
Download the source from:
Save it in the working directory.
Configuring Ant Build Properties
Copy “default.properties” to “local.properties”:
cd benchmarks cp default.properties local.properties
Edit local.properties and add:
build.failonerror=true java14.lib=/usr/lib/jvm/j2sdk1.4.2_19/ java15.lib=/usr/lib/jvm/jdk1.5.0_22/ java14compile.classpath=/usr/lib/jvm/j2sdk1.4.2_19/lib/ java15compile.classpath=/usr/lib/jvm/jdk1.5.0_22/lib
The failonerror property is useful for debugging.
Fix some Build Files
Fix the Eclipse URL in bms/eclipse/build.xml
Fix the svn repo URL in bms/jython/build.xml
Daytrader requires Java 1.5, but the rest of the suite uses 1.6. To get around this problem, follow the instructions as advised by Diogenes Nunez on the DaCapo mailing list.
[Updated 26/05/2015 – thanks to Peter Hofer]
The Daytrader benchmarks are built with Maven, which tries to download artifacts from repositories at codehaus.org. Unfortunately, Codehaus is shutting down their services, and instead of serving HTTP 404 for the missing artifacts, their web server serves an HTML page which Maven happily accepts as POM and JAR file content. Obviously, this causes the build to fail. Since I could not find a way to prevent Maven from accessing specific repositories, I worked around this issue by adding the following to /etc/hosts:
Checksums for Jython and DayTrader
Remove the jython checksum file:
Similarly, remove checksum for bms/libs/daytrader:
rm libs/daytrader/downloads/geronimo-jetty6-minimal-2.1.4-plugins.tar.gz.MD5 rm libs/daytrader/downloads/jstl-impl-1.2.jar.MD5 rm libs/daytrader/downloads/daytrader-svn-767347-src.tar.gz.MD5
Info. from Peter Hofer:
“I encountered an error during the xalan build, where for a recursive invocation of ant, the environment variable ANT_HOME is set to the value of the “ant.install” ant variable. I had to explicitly set this ant variable with an additional entry in local.properties: ant.install=/usr/share/ant”
Peter Hofer had some problems with his environment:
“Setting JAVA_HOME was not sufficient in my environment. I found that various other Java-related variables were pre-set in my openSUSE installation (JAVA_BINDIR, JAVA_ROOT, JDK_HOME, JRE_HOME) and at some point the build favoured one of those over JAVA_HOME, leading to errors, for example when starting Geronimo. After unsetting those other variables, the build completed successfully.”
This took 25 minutes on my 64-bit Linux box with a quad-core Intel i5-3550 @ 3.3 GHz and 8GB RAM.