Curious Kaffe vs. jdk speed test results under Linux

[Maxim Kizub]

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


BTW - why?
I can think only about one way a jit may produce a better code, then
compiler - it knows the runtime information - method's and field's
offsets in virtual table and class.
But, from the other point of view, jit cannot know these offsets
for not-yet-loaded classes, and the generated code can't relay
on this...
I really do not see difference between jit and compiler, except
jit slows down the start of a program.

BTW, can someone explaine me how kaffe produces code for
fields access and method calls for not loaded classes? Trying to
do this by looking at kaffe's code is as easy as for egcs code ;-)

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

Hmm? Is there a standard interface to egcs compiler for this?
BTW, I'd like to remember, that kaffe uses pizza, and there are
other compilers (you know ;-) ), which whould be hard to use
with egcs, since it will support only pure java gramma.
I don't know current status of egcs (their mail-list is broken,
or maybe nobody uses it?), but looks like those guys read this
mail-list ?!

Do you know, that GNU $Classpath project goes on?
You really do. And they have a special interface for
different JVM's (i.e. their java.lang.Class and other JVM
specific classes are only wrappers about special
classes written by JVM developers). There was a proposition
about adding some standard interface to egcs-generated
code - why not use the interface proposed by $Classpath?

And about egcs and other java extensions - why not make
a standard wrapper class (the interface to gcc) to make
others (pizza/kiev/kawa/etc) to be able use gcc/egcs as standard
backend for native code generation? I tryed to make this
interface myself, but I really can't understand egcs java code
without help from developers :-|

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

I'd prefere the "fat" bytecode model. It can be used not by kaffe
only, and by kaffe - as easy as by other JVMs.

Regards
  Maxim Kizub