Jeff Sturm wrote:
> "Etienne M. Gagnon" wrote:
>
> I can see why it would seem that way. The gcj project has made a great deal of
> headway since the merge. More, it seems, than the free VM projects (or perhaps
> I just don't hear as much about those).
Maybe you should give a look around... There are the ORP, Kissme, and
SableVM projects that have shown up lately.
>
>>is incompatible with precise garbage collection schemes,
>>
>
> False.
I disagree with you. For example, assume a "stop the world copying
collector". Some VM thread is running Native CNI code, and another one
is running Java code. The Java thread requests memory (NEW), this
triggers gc (low memory condition). What should the VM do? Wait for
the CNI code to finish? It might never do so (base awt thread, or
whatever). So this is not a good idea. OK, so let the Java thread copy
(thus move) objects while garbage collecting. The problem is, how is
that Java thread going to get the content of registers of the CNI
threads, to collect all the roots? Morever, how is it going to preclude
the gcj compiler from "optimizing" field access, so that the Java thread
can easily update all the references stored in registers/memory used by
the CNI thread? Unless you are telling me that the VM should go through
a very complex communication protocol to synchronize its work with the
CNI modules? How would you implement this without adding overhead to
CNI? Or, maybe you are assuming a "non-moving" collector in a single
threaded environment?
>>or bidirectional object layout, etc.
>>
>
> ??? (unfamiliar with this term)
>
it is described in my paper at the JVM'01 conference, and available
online at:
http://www.usenix.org/events/jvm01/technical.html
>>(2) It is pretty difficult (if not impossible) to make a good CNI->JNI
>>code converter, and even if such a thing was built, I doubt it would
>>make an optimal use of JNI (by caching MethodIDs and FieldIDs).
>>
>
> I think you can find a subset of CNI and JNI however that is very similar.
>
> Caching method/fieldIDs is painstaking work, as is exception handling in JNI. I
> once used C++ wrapper classes for JNI work that made it quite a bit more
> palatable (and more CNI-like). These classes could cache field/method lookups
> whenever appropriate. If I still wrote any JNI code, that's what I would do.
I again disagree with you. Unless a JVM is compiled with the
appropriate C++ compatibility flags, it might anyway be incompatible
with C++'s exception handling. Exception handling as the other things
are pretty simple in JNI, as long as you have read and understood the
user manual, specially if the code you write is very short (as it should
be in the native part of the class libraries).
>
> Why not just contribute to classpath? I don't imagine they would refuse JNI
> contributions. (Is there even any CNI code in classpath? I haven't looked
> lately.) Forking seems like overkill for what you want to accomplish.
There's still the licensing issue. The Canadian government, and
Canadian Universities are not very hot about the idea of giving
intellectual property to a US (not for profit) corporation.
> I don't understand... what additional restrictions are imposed by the LGPL?
If there aren't, then why not use the LGPL? :-)
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
