"Aaron M. Renn" wrote:
> First, do you consider yourself:
>
> a) A standalone JVM that compiles everything to native in order to run it
> b) A JIT plug-in for existing JVM's.
> c) both
Definitely (a). In order to get high-performance EF retains a lot of control over
object layout, method dispatch, garbage-collection, type representation and so
forth. Some of the assumptions are laid out in the documentation, but others are
scattered throughout the code:
http://www.mozilla.org/projects/ef/techdocs/machine_model.html
Combining the EF code with another JVM would be a non-trivial task since we would
need to reconcile all these low-level decisions between the two JVMs.
Later on, we might consider adding a bytecode interpreter to avoid the overhead of
compiling rarely-executed methods, e.g. static initializers. However, this would be
conceptually a matter of adding an interpreter module to the EF compiler rather than
the other way around.
> If it is (a), then you might want to make use of the Classpath libraries
> directly. This is really not too hard, but requires some work. Basically
> we expect that some of the lowest level functions of the JVM (parts of
> java.lang and reflection) be implemented in the JVM itself.
I believe that our support for java.lang.reflect is nearly 100%. There is also a C++
API to access these methods. If required, we could put C wrappers around them so
that Classpath could access them.
> There is a
> document on our web site (http://www.classpath.org/) that explains this in
> more detail. John Keiser ([EMAIL PROTECTED]) wrote it and knows the most about
> what is needed. For Japhar, things were very simple. It already wrote most
> of what we needed for supporting the Sun JDK libraries and we were able to
> hook into it quite simply. For EF, some investigation would need to be
> done. Once that is done, everything should be ok.
The document is helpful, but what would really be great is an API spec that lays out
all the methods and classes that a VM needs to implement. In an ideal world, someone
working on implementing them would never need to read the Classpath code.
> gotcha I see is that we load our own native libraries and I'm not sure how
> JIT's Java routines interface with existing native code.
Native code loading is done on a per-method basis, not a per-class basis. If you are
saying that it's possible for Classpath and EF to define the same JNI-callable native
method (same class, method name and signature), then we would indeed need to sort
that out.
> Next, I see that you are written in C++. Both Japhar and Classpath (and
> Kaffe as well, I believe) use C exclusively. Interfacing between the
> languages is easy, but the use of C++ does tend to make EF run on fewer
> systems as not everybody has a C++ compiler.
That's a good point. However, if you look over the code, you can see that EF is not
a C program with a C++ facade. It makes very heavy use of C++ idioms, especially
templates. A port to C would be a substantial undertaking.
A couple of years ago, I would have been more concerned, but C++ is mainstream enough
that I think that almost anyone who wants a conformant C++ compiler can get their
hands on one.
> Lastly, could rename the project back to "Sexual Chocolate"?
In order to do that, we would need an appropriate logo. Maybe you can find one ? :)
-Scott
