Curious Kaffe vs. jdk speed test results under Linux

[Godmar Back]

> 
> > 1. Use egcs/gcj to make native-method versions of everything, assuming that
> >   its output can conform to the JNI.
> 
> I don't know what you mean by "conform to the JNI".  For me it means
> a performance-killer.  Having a compiler generate native code that
> uses the JNI to interoperate with the JVM sounds nice, because it
> means the compiled code can be linked with any VM that supports JNI.
> The problem is that the resulting code may well be slower than interpreted
> code, which kills the point of compiling it.
> 
> Hence the philosophy of gcj is to generate code for a *specific*
> JVM, and to have the compiler know the layout of objects and classes
> of that VM.
> 
> The run-time library that goes with gcj will be released *very* soon
> now.  However, it is not as featureful as Kaffe. 
> 
> While we have no immediate plans to document the interface between
> the compiler and the run-time library (it is is far from stable at
> this point), having the library will make it easy to figure out.  
> 

 Per,

may I ask you what your (or Cygnus's) point of view on using egcs for
other VMs is?  For instance, Geetha Manjunath <geetham at india.hp.com>
reported that they too had to modify egcs in order to account for the
different layout of class meta-data in libjava compared to their VM.

It seems to me that one possibility of doing that would be to
modularize the egcs code to allow for VM-specific different modules,
which include all VM-dependencies.  These modules could then be activated
with a cmdline switch.  As these modules are VM-specific, they would have
to be developed and maintained by the developers of a given VM.
Does this sound like a feasible plan to you?  Has any effort been 
made to modularize egcs in this fashion?  How hard do you think that
would be?

thanks,

	- Godmar