Re: dacapo benchmarks

[Andrew Haley <aph at redhat dot com>]

Patrick Olinet writes:
 > Hi Andrew,
 > 
 > >  > * The eclipse benchmark from the same suite runs fine with gcj, except
 > >  > that the results aren't very good. Actually, the results are hardly
 > >  > better than what you get when you run the eclipse benchmark with gij.
 > >  > Compare to the others benchmarks results (antlr, hsqldb, luindex,
 > >  > lusearch) where gcj outperforms gij by a factor of 5 or even more, I'm
 > >  > a bit suprised. And using "-O2" or "-Os" for gcj invocation doesn't
 > >  > help.
 > >
 > > I'm guessing that eclipse isn't actually spending much time in the
 > > application program itself, but in the libraries.
 > 
 > You're right. I've first thought that this wasn't the problem since
 > the whole jar files are compiled into the binary. But after looking
 > more carefully at the content of one of them, I can see a big
 > "eclipse.zip" file that contains all the eclipse libraries (class +
 > jar files). This zip file is put into the binary as it is and its
 > content is not compiled by gcj but loaded and interpreted at runtime.
 > That's the reason why. And this would require modifiying the benchmark
 > code to get rid of this behaviour.

I'll tell you what we do at Red Hat / Fedora / etc.

We have a global database of compiled code.  You can find out where
this is by typing `gcj-dbtool -p'.

We have a script called aot-compile which compiles a bunch of jarfiles
in one directory into a database (.db) file and a bunch of shared
libraries in another directory.  And we then copy that directory info
/usr/lib*/gcj.  For example, on my machine the eclipse-ecj package
looks like this:

/usr/bin/ecj
/usr/lib64/gcj/eclipse/org.eclipse.jdt.core_3.2.1.v_677_R32x.jar.db
/usr/lib64/gcj/eclipse/org.eclipse.jdt.core_3.2.1.v_677_R32x.jar.so
/usr/share/eclipse/plugins/org.eclipse.jdt.core_3.2.1.v_677_R32x.jar
/usr/share/java/eclipse-ecj.jar
/usr/share/java/jdtcore.jar

Once the shared libraries and .db files are installed into
/usr/lib64/gcj, we update the global gcj database with the command
'rebuild-gcj-db'.  And from that point, whenever gcj tries to load
bytecode it will look aside to the databases of precompiled code and
use that in preference.

(You don't have to use the gloabl database, you can have a local one
instead, but this way is simplest.)

Andrew.