SpecJVM98 (was: assembler warning when compiling obfuscated bytecode)

Tue Nov 30 10:14:00 GMT 1999

>>> Godmar Back <gback@cs.utah.edu> writes: 
>> > Btw, has anybody tried compiling/running the Spec98 benchmarks yet?
> > I remember seeing mail about it, but nobody ever reported success
> > to my knowledge. It would be nice if we had a recipe somewhere of
> > how to compile them.
>> I've compiled three of the tests with source available (compress,
> db, and mtrt/raytrace), but it required a few tweaks because of
> problems with gcj (see PRs gcj/80 and gcj/109). One of the three
> (raytrace) still doesn't
> work correctly (the raytrace result is correct, but the validation
> phase doesn't work, there is some problem with a PrintStream but
> I haven't checked it out in detail).
>> The harness (SpecApplication) does compile if all the gui stuff
> is cleaned out.
>> Hopefully someone has done more??

I was able to compile everything from its .class file with -O3,
minus two class files that trigger that exception related bug
I reported in GCJ/112.
[With Kaffe, it's not a show stopper, since I can just-in-time compile
those missing classes, and they're part of the harness anyway, so shouldn't 
count towards the time spent in the benchmark.]
However, this was against Kaffe's class libraries, so it's only
an indication of what bytecode gcj can already handle, not of the
coverage libgcj currently provides.
Why did you try from source anyway? It seems your chances are generally
much better from bytecode, from my experience at least.
My initial results of running them are rather disappointing: javac, jack
and mtrt don't work yet (which is probably *not* a gcj problem, I hope),
the rest run, but except for compress and mpegaudio they're all (jess, 
jack and db, that is) a lot slower than with Kaffe's jit. All are slower
than IBM's. The most promising is mpegaudio which went from 95 seconds
to 38 seconds (IBM: 26 seconds). I wonder how fast libgcj would be.
(There's of course different allocators/collectors.)
I need to reread the mail about what changes I need to make to gcj
to get full inlining of private methods. I think I have to say 
-finline-functions in addition to -O3, which I didn't.
I attribute the slowdown in jack to gcj's exception path, the slowdown
in db might be due to the slower interface dispatch (though I do implement
a similar cache as libgcj does, I should look at its hitrates), some slowdown 
might be due to the fact that gcj doesn't have inlined synchronization and 
incurs a function call on each monitor enter/exit, and then of course 
there's the millions of partially unnecessary calls to Jv_InitClass all 
over the code. But only profiling will tell.
	- Godmar
ps: the current state of the kaffe integration is checked in kaffe's 
repository in case anybody else wants to play with it.