Curious Kaffe vs. jdk speed test results under Linux

[Godmar Back]

> 
> I see two ways that this can be done:
> 
> 1. Use egcs/gcj to make native-method versions of everything, assuming that
>    its output can conform to the JNI.
> 

egcs does not use the JNI calling conventions.  I'm not sure if it can
be told to do so.  In any event, setting up a JNI call frame for every
method invocation incurs overhead.  It incurs tremendous overhead the
way it's currently done in Kaffe's interpreter.  This is in part because 
signatures are parsed for every method invocation.
For the translator, the overhead may be less high, but still not so low 
that we would want to pay it.

> 2. Make an add-on to kaffe that does JIT to produce PIC, then re-write the
>    class files, embedding the PIC in an attribute instead of the original
>    bytecode.  The resulting class file will sit with compilers and other
>    java tools (except for javap/javad) just fine, but only kaffe can execute
>    it.

This is also known as "fat binaries".
The main problem with that is that the quality of the resulting code is
as low as the quality of the code produced by kaffe's translator.

> 
> I'd rather not delve into the bowels of ecgs - trying to figure out something
> by looking at that code is not easy.
> 

There are certainly other possibilities; but all things considered, it is
my opinion that there is no alternative to using egcs in the long term;
and while becoming familiar with egcs is certainly no easy, I am convinced
that resources are best spent there.  Also, I don't think one will need
to understand egcs completely in order to do that.

Ideally, egcs would have a '-kaffe' switch to produce kaffe compatible .so
files.  Of course, for that to happen, there are also other obstacles
to overcome, which may show up as a result of the fact that the respective
copyright owners,  Cygnus and Transvirtual, are competitors.

	- Godmar