Curious Kaffe vs. jdk speed test results under Linux
gback at cs.utah.edu
Sat Jan 2 12:21:22 PST 1999
> > 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.
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
More information about the kaffe