harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: State of the World
Date Tue, 10 May 2005 15:49:28 GMT
Ben Laurie wrote:
>> * Fragmentation.  I think there are too many free JVMs.  In particular
>>   the "C/C++-based VM" niche is over-full.  It ought to be possible,
>>   though difficult, to write a configurable core VM that can be reused
>>   by other projects.  The idea here is, have a reusable reference
>>   implementation, and reduce writing a VM to writing an execution
>>   engine (and perhaps a GC).
> This is certainly my understanding of the "modularity" aim, and one of 
> my two main interests in this project (that and security, natch).
> Like they said, pointers to where you think the natural fault-lines in a 
> JVM are would be most illuminating.

Hi all,

I'm the author of JCVM [1] and a contributor to Classpath. Some quick

Harmony sounds like a good idea overall and I like it. IMHO the more
free software and options for people to play with and improve the

As for the above idea of a "modularized" VM core, I'm a bit skeptical.
To me it's a bit like saying, "Why are there so many open source UNIX
kernels? Why isn't there a single modulurized kernel on which the Linux,
FreeBSD, NetBSD, etc. kernels are based?"

In other words, for something as tightly entwined as a Java VM, there
are invariable compromises when you modularize things. Sure you can
write APIs for the execution engine and the garbage collector, but
that's going to seriously hamper the ability to do the coolest kind
of optimizations (and performance is a goal here, right?)

Not saying it's a bad idea -- rather, it's a neat idea and a very
interesting challenge technically. However, who is going to do the
work? The existing VM authors are not going to be interested in
moving their code to this modular core when the ultimate result is
simply a slower version of their existing VM. So probably what will
happen is that yet another Java VM will be written basically from
scratch -- not necessarily a bad thing, just a prediction (in any
case, I did that too and it was fun :-)

Another data point... look at how many Classpath-based VM's use a
"stock" version of Classpath. I'd guess it's less than half. Why?
Because various VM peformance and/or design issues mean they need
to change things. If we can't even get all the existing Classpath
VM's to conform to the same Classpath-VM API, which is overall much
smaller than a modular VM API would be, that doesn't bode well.

Finally, I'm happy to offer any portions of JCVM that would be useful
to Harmony, and can change the license if necessary (I'm not religous
about licensing). E.g., some of the tedious stuff like the ZIP file
reader (based on libz).


[1] http://jcvm.sourceforge.net/

Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

View raw message