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:[EMAIL PROTECTED] |
| 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:[EMAIL PROTECTED] |
| 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/ |
+--------------------------------------------------------------------+
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
