SpecJVM98 (was: assembler warning when compiling obfuscated bytecode)

Tue Nov 30 11:22:00 GMT 1999

I believe the bitmap-based marking work is still in progress. The code in
the GC exists, and Tom Tromey was working on the libgcj side of things,
though I gather he's been getting some higher priority interrupts.
There are some hooks in the collector to reduce allocation locking by
keeping per-thread free lists, though they currently don't play with some of
the other facilities that gcj uses. I think it's fairly easy for me to add
that support once the bitmap-based marking code is in place. (This is
nowhere near a complete solution to MP scalability in the collector. But
it's a first step.) 
I haven't tried SPECjvm. Based on experiments with my GC benchmark and the
UCSD benchmark a while ago, my impression was that the gcj, the IBM jdk, and
the kaffe jit were, at the time, not grossly different in code quality on
X86. (For both gcj and kaffe, he UCSD benchmark was dominated by the
exception handling test which, in my opinion, is even less realistic than
the rest of the benchmark. I tried to factor that out. I don't think the
UCSD benchmark makes any calls through interfaces.)
My problem with kaffe was the GC benchmark, on which it lost to even the
Blackdown JDK, and lost by a factor of 4 to gcj. Has anybody looked more
closely at why this is? Is there a good reason for it, e.g. an (overzealous
on a PC?) attempt to keep the heap small?
Hans
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, November 30, 1999 11:00 AM
To: Godmar Back
Cc: warg@ce.chalmers.se; java-discuss@sourceware.cygnus.com
Subject: Re: SpecJVM98 (was: assembler warning when compiling obfuscated
bytecode)
Godmar Back wrote:
> Why did you try from source anyway? It seems your chances are generally
> much better from bytecode, from my experience at least.

Perhaps... but in my understanding gcj optimizes better when compiling
from source.
> 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 don't have access to SpecJVM98 and haven't tried javac or jack. I
tested with some real applications here though, and find gcj/libgcj
sometimes _outperforms_ IBM by 30% or so. That was with Alexandre's
inlining patches, no threads and static linking. With threads it is
slightly slower, partly due to spinlock overhead in the allocator.
I haven't looked at Kaffe's runtime at all.
> 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.

The -finline-functions flag is assumed by -O3. You need Alexandre's
patch to calls.c (only if it isn't part of the gcc trunk yet) and you
may need to reorder private methods so they are declared before they get
called.
> 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.

Profiling does help on non-threaded code. Unfortunately it tells
nothing about synchronization, which is pointless without threads.
I remember reading that someone's working on new bitmap-based marking
code for boehm-gc. That should improve GC performance in libgcj (what
does Kaffe do?). 
Also I heard the gcc backend is being rewritten for inlining at the tree
level, so integrate.c may not be needed anymore. I've suspended my
investigation into method inlining until this work is committed. For
now, final/static methods in external classes cannot be inlined, which
is clearly bad...
Exceptions don't tend to occur often in application code, so I consider
them a lower priority.
-- 
Jeff Sturm
jsturm@sigma6.com