SpecJVM98 (was: assembler warning when compiling obfuscated

[Godmar Back]

> 
> 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.

You're right.

> 
> > 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 would love to try those apps too.  Are they available?

In the case of SpecJVM98, I somewhat reject the implication that
those are benchmarks while everybody else is running "real applications".
If you look at them, you'll find they're actually all applications that 
people thought were "real" when they wrote them.  They became benchmarks
only after being included in the Specs.

> 
> 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.

Thanks, I'll check that. 

> 
> > 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 was referring only to the call overhead due to the outlined calls,
not other costs of synchronization as discussed in earlier threads.
Profiling should show me that.

> 
> 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?). 

I implemented bitmap based marking for objects.
I think the object scanning part of kaffe's gc is mostly okay, but 
Kaffe's allocator, marker and sweeper are still in need of revision.

> 
> Exceptions don't tend to occur often in application code, so I consider
> them a lower priority.
> 

This is the traditional point of view, and it's probably still true for
the most part.  Nevertheless, it would be nice to be able to speed up
exceptions that the run-time system detects are thrown often, similar
to how a hotspot-like system may decide to optimize a frequently
invoked method.  I could imagine dynamically generating code to
implement the stack unwinding for such frequently taken paths.

	- Godmar