Curious Kaffe vs. jdk speed test results under Linux

[Godmar Back]

[About jit vs. wat]
> 
> 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.

I did not mean to make any statement about the potential quality
of code produced by JIT vs. WAT compilers.

What I'm saying is that gcj, being a front-end to egcs, has egcs's
optimization machinery available.  Kaffe's jit, on the other hand,
perform zero optimizations, and the performance of the resulting code 
is accordingly.

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

The interface to the VM upon which egcs-generated code relies is the
interface provided by Cygnus's libjava.  See Per Bothner's mail.

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

No, egcs can read both Java sourcecode and Java bytecode.
It will not understand modifications to the bytecode format, but it will 
accept bytecode generated by other compilers such as kiev (kiev can be
made to produce sun-compatible bytecode that would pass verification, 
can it not?)

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

The interface defined by Classpath is a different kind of interface.
It is an interface that a VM must implement in order to use Classpath's
implementation of the run-time libraries.  

For Kaffe to use Classpath as a replacement for its run-time libraries,
someone would have to implement this interface for Kaffe, which is also
a worthwhile project.

	- Godmar