Re: Classpath future?

[Etienne M. Gagnon]

Nic Ferrier wrote:

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


Yep, right on the point.  The problem is that native code shouldn't 
directly access fields.  It is not with pleasure that Sun decided not to 
give direct field access, it is because such access inhibits many 
things, like moving collectors, unless you design a complex, VM specific 
protocol around native calls, which is excactly what CNI intended to 
simplify.

FYI, the only available native interface in Sun's most important VM 
(HotSpot), is JNI.  This is because this VM wants the freedom to play 
around dynamically with object placement and layout.  Only through 
indicect field access (as done in the JNI) can you have such freedom.

I really think that a separate "pure ANSI/ISO/POSIX C + JNI" (OK... only 
as pure as possible...) native tree should be maintained in Classpath. 
GCJ programmers could contribute to a separate CNI tree (under the 
condition that both trees are kept relatively synchronized;-).

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


Personally, I would be ready to help restructuring a few things.  I am 
already doing to simplify SableVM's users life.

See my other message about splitting the Java/native stuff.

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


Agreed.

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


Agreed, too. :)


Etienne



--
+--------------------------------------------------------------------+
| Étienne M. Gagnon                    mailto:address@hidden |
| Professeur adjoint            Téléphone: (514) 987-3000 poste 8215 |
| Bureau: PK-4930                        Télécopieur: (514) 987-8477 |
| Département d'informatique, UQÀM          http://www.info.uqam.ca/ |
| Auteur de SableVM                          http://www.sablevm.org/ |
| et de SableCC                              http://www.sablecc.org/ |
+--------------------------------------------------------------------+
| Etienne M. Gagnon                    mailto:address@hidden |
| Assistant Professor                Phone: (514) 987-3000 ext. 8215 |
| Office: PK-4930                                Fax: (514) 987-8477 |
| Department of Computer Science, UQAM      http://www.info.uqam.ca/ |
| Author of SableVM                          http://www.sablevm.org/ |
| and SableCC                                http://www.sablecc.org/ |
+--------------------------------------------------------------------+