[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Classpath future?
From: |
Etienne M. Gagnon |
Subject: |
Re: Classpath future? |
Date: |
Thu, 12 Jul 2001 11:19:55 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux 2.4.6-586tsc i586; en-US; rv:0.9.1) Gecko/20010620 |
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/ |
+--------------------------------------------------------------------+
- Re: Classpath future?, (continued)
- Re: Classpath future?, John Keiser, 2001/07/12
- Re: Classpath future?, Aaron M. Renn, 2001/07/12
- Re: Classpath future?, Etienne M. Gagnon, 2001/07/12
- Re: Classpath future?, Aaron M. Renn, 2001/07/12
- Re: Classpath future?, Etienne M. Gagnon, 2001/07/12
- Re: Classpath future?, Brian Jones, 2001/07/12
- Re: Classpath future?, Tom Tromey, 2001/07/12
- CNI, Paul Fisher, 2001/07/12
- Re: Classpath future?, Tom Tromey, 2001/07/12
Re: Classpath future?, Jeff Sturm, 2001/07/12
- Re: Classpath future?,
Etienne M. Gagnon <=
- Re: Classpath future?, Jeff Sturm, 2001/07/12
- Re: Classpath future?, Etienne M. Gagnon, 2001/07/12
- Re: Classpath future?, Jeff Sturm, 2001/07/12
- Re: Classpath future?, Etienne M. Gagnon, 2001/07/12
- Re: Classpath future?, Jeff Sturm, 2001/07/12
- Re: Classpath future?, Etienne M. Gagnon, 2001/07/12
- Re: Classpath future?, Brian Jones, 2001/07/12
- Re: Classpath future?, Brian Jones, 2001/07/12
- Re: Classpath future?, Tom Tromey, 2001/07/12
Re: Classpath future?, Mark Wielaard, 2001/07/12