Curious Kaffe vs. jdk speed test results under Linux

[Tim Wilkinson]

I'm very much in favour of seeing all the native libraries move to JNI,
mostly because it's a pre-requisit(sp?) to improving the GC (as you
observe).  It would also allow us to reduce the size of Kaffe since we can
eliminate a bunch pof code which supoorts the old KNI interface.

Tim

On Sun, 3 Jan 1999, Godmar Back wrote:

> > 
> > On Sun, 03 Jan 1999, Godmar Back wrote:
> > >..However, new native code (such as the awt 
> > >code) should be written to use JNI, and JNI versions of some of the native
> > >classes are welcome too...
> > 
> > The AWT already is JNIed. But you have to care for your design a lot if it comes
> > to a complete move to JNI (speed-wise, "unhand()" is dramatically
> > better than a callback). There is a talk I gave about this topic on the papers
> > webpage ("going native with Javas JNI..", I think).
> > 
> 
>  My take on this is that the complete move the JNI only makes sense if
> accompanied by a move to a more advanced generational collector that
> actually requires JNI and compensates for it.
> 
> Nevertheless, I am in favor of a transition path that converts all those
> methods that are likely to not be frequently used even before such a gc is 
> available.
> kaffe.lang.UNIXProcess.forkAndExec is one example.  Clearly, what methods
> are frequently used does depend on the application you're running.
> 
> There is two more options:
> One other option that we have is to make the use of JNI optional; i.e.,
> to maintain two versions of certain native libs, a JNI and a non-JNI version.
> 
> Even with a more advanced gc, we would also have a third option: namely
> to handcraft the non-JNI library code such that it coexists with the 
> collector.
> 
> 	- Godmar
> 
>