Re: Classpath future?

[Etienne M. Gagnon]

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: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/ |
+--------------------------------------------------------------------+