Re: SpecJVM98 (was: assembler warning when compiling obfuscated bytecode)

[Jeff Sturm <jsturm at sigma6 dot com>]

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