Re: Classpath future?

[Nic Ferrier]

>>> "Etienne M. Gagnon" <address@hidden> 12-Jul-01 4:01:30 PM
>>>

Aaron said: 
> Solving the CNI/JNI issue is an outstanding point.  
> I do not see us ever abandoning JNI as it is the Java 
> standard.  However, JNI has substantial performance 
> penalties and creates bogus looking code.

Etienne replied:
  This is not the case for "short methods". 

The real problem with JNI is access to class member variables. CNI
compiled code can access Java member fields directly (and vice versa
AFAIK) thus raising the possibility of better inlining. JNI has to use
function calls to get at that stuff.

This is the major problem with Classpath/GCJ integration because it
screws up any chance of doing things automatically without changing
the structure of some of the current Classpath code.

It *can* be achieved without affecting Classpath's suitability for
other VMs. I am working on better build systems for Classpath as part
of my work to get Kaffe working (this is going very slowly because I
don't have much time - but it is getting there).

For example, consider the String class. GCJ use a native method to
intern() strings. Classpath uses some pure java. Leaving aside the
merits of the two we could enable a VM specific String class by
providing:

- a VMString and a String that extends it
- a String with a VMString which is called by it

We don't have to do that for every class, but maybe we have to do it
when VMs using Classpath want to provide functionality. IMHO it
shouldn't be that big a deal.


Aaron said:
> My guess is that we will ultimately end up with two 
> versions somehow selected at compile time via a 
> configure flag.

In my personal view that would be a shame. It would be nicer if we
can have a single Classpath that VMs can integrate and improve on. 

In practice that means thinking carefully about what a VM might make
native, working with GCJ is very good practice for working with
perhaps less demanding VMs.


Nic