Re: Free Java (Was: Trouble with VM?)
José Fonseca wrote:
I know that competition is natural (and quite often favorable) in
open-source. But I can't help thinking I may be backing the wrong horse,
and my time spent on it be in vain.
The different Free jvm's have different goals and constraints. I will
describe my view of 3 jvm's I know.
GCJ is mainly a GCC extension, targeting static compilation of Java to
native code and/or bytecode. It includes a minimal, but incomplete
interpreter (gij). Its main native interface is CNI (Cygnus Native Interface)
which is convenient for linking with C++ code, but which is non standard
(incompatible with JNI) and is also incompatible with precise and moving
garbage collectors. It's class library is mostly GNU Classpath with
some differences (both projects "libgcj" and "Classpath" are under an on
going merge). License is GPL with a linking exception (which makes the
whole license very weak, intentionally).
Kaffe is the oldest of the Free jvm's. It has, currently, the best class
library support (but implements quite old JDK versions; minimal support
for latest libraries). Dalibor and others are currently working on making
Kaffe to work with GNU Classpath class libraries. Kaffe has a JIT compiler
and thus achieves very good performance, usually. Kaffe's primary native
interface is gain a Kaffe-specific interface. JNI has been retrofitted
to Kaffe; but Kaffe remains an unsuitable Free jvm to experiment with moving
and precise garbage collectors. One of Kaffe's main "features" (or limitation,
depending on you point of view), is that it is licensed under the GNU GPL,
with NO exception whatsoever. This can have important consequences on an
application that depends specifically on features of Kaffe.
[WARNING WARNING WARNING: I AM BIASED TOWARD SABLEVM]
SableVM is a newer project that was started from the ground up to build a
robust, extremely portable, efficient, and fully specifications-compliant
(JVM spec, JNI, Invocation interface, and soon to come: JVMDI, JVMPI(?),
etc.) jvm that would be *EASY* to maintain and to extend. SableVM's core
engine is an "interpreter: which uses state-of-the art techniques to deliver
performance that can approach that of a "naive" just-in-time "JIT" compiler,
while retaining the software engineering advantages of interpreters: portability,
maintainability, simplicity. [Debugging a JIT can be a quite challenging
problem in a multi-threaded environment]. SableVM's simplicity makes its
source code very accessible, and easy to understand for new users/programmers.
SableVM's internal design was engineered to be as flexible as possible. SableVM
is compatible with moving and non-moving collectors, provides "constant-time"
interface method calls (in fact, there is no time difference between a
virtual method call and an interface method call at runtime). SableVM's whole
source code is currently < 60K lines, yet it provides properly guarded native
JNI method transition, so that garbage collection does not have to wait for
a runaway native thread to call back in the jvm to be able to do garbage
collection. It has many other *robustness* design features, that have been
the object of careful design. While SableVM does not currently implement
all the different specifications, and has some incomplete parts (e.g. it lacks
a bytecode verifier), it has all the structures in place so that the full
specifications can be implemented without having to re-engineer the core design.
This is not the sort of stuff that is easily visible to an end user, but on the
longer term, it will allow SableVM to be an utterly ROBUST (and hopefully complete)
jvm for executing Java bytecode. [We do have a SableJIT project, which is a
"retargetable" JIT (easily portable to a new platform with minimal effort), that
is already capable of compiling hot paths of methods, but it is NOT an optimizing
JIT, nor can it fully compete with platform-specific JITs].
SableVM was designed from the ground up to work with GNU Classpath, and solely use
the standard JNI interface as native interface (it has no other native interface).
It is extremely portable (porting to Debian/hppa took only 25 minutes)!
Usually, you can expect SableVM to be ~5 times slower than a high-performance,
state-of-the art JIT (including Kaffe's JIT3). Yet, SableVM's interpreter is in average
~4-5 times faster than Kaffe's *interpreter* (which was not designed with performance in
head; to be fair). The big difference is: simplicity (size and understandability of code)
and portability (porting an optimizing JIT takes months), and robustness (debugging an
interpreter is easy; debugging a JIT can be a nightmare).
Oh, yes! SableVM is licensed under the LGPL, so there are no worry to have about linking
with applications, or even extending SableVM to provide specific features, and link
proprietary, or GPL-incompatible applications to it. Please refer to recent thread of
discussion on Debian-legal for a better understanding of the potential problems of
a GPL'ed virtual machine[0]. The FSF's interpretation is even stricter than Debian-legal's[1].
There exist "hypothetical" plans to eventually combine some of these projects. Given SableVM
license compatibility, one could very much imagine using SableVM as a replacement for gij
to interpret dynamically loaded bytecodes faster within a gcj-compiled application. Also, one
could see SableVM as providing a fast interpretation engine in a mixed mode interpretation and
JIT compilation of hot methods Kaffe-based system.
[END OF BIASED SECTION :-)]
What you will find as common thread, in these 3 systems, is the following: All three systems
aim to depend on a SINGLE class library: GNU Classpath. Most of the needs are in the class
libraries, as the java language has gigantic class libraries. Currently, Classpath is >500K
lines of code (yes, that's half a million). If you want to help, just help Classpath, and
you'll be helping all Free jvm's that depend on it.
Of course, I would tell you to do so using SableVM, but I am biased. Dalibor made such a
great point of remaining so very objective about the matter!
<BIASED-SECTION> Using SableVM, what nice is that if you have a bug, the interpreter is really easy
to debug, yet, it delivers quite an acceptable performance during interpretation. Also, if you
ever wanted to look at the internals of a jvm, SableVM provides a really neat internal structure.
</BIASED-SECTION>
In any case, pick your preferred GNU-Classpath based Free jvm, and start helping. Everybody will be
happy, even people of the other jvm projects.
Etienne
SableVM project leader
[0] http://lists.debian.org/debian-legal/2003/debian-legal-200311/msg00012.html
[1] http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Reply to: