Symbolic +1
Sounds like the way to go.
Craig
On May 20, 2005, at 12:01 AM, Steve Blackburn wrote:
Weldon Washburn wrote:
On 5/19/05, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
This is why I would like Harmony to have two VMs, one written in
java
and one written in C-or-friends: this would give us
Well, I suspect if we design the interfaces correctly, we could do
the
above with one JVM instead of two. Two competing Harmony
implementations means ultimately one of them must die.
I envisage that harmony is *seeded* with two VMs. Under the
"seeding" model both seeds are destined to die (that is, their
*cores* die) once new core/s evolve. I view this as a good thing.
Harmony really
needs one quickly evolvable code base. The concept is to write the
JVM in 100% C/C++ today. Rationale: C/C++ is battle tested for
building OS and compiler systems.
As for a language "battle tested for building compiler systems", I
think Java has well and truly earned that badge (javac? antlr?
soot? jikesrvm?...). I don't know about an OS, but we're not
building an OS. We have pushed Java hard in Jikes RVM, and as a
long time C/C++ systems programmer who 6 or so years ago started
working on a Java-in-Java VM, I for one can say "I never want to go
back!" :-) As an apache project, we should be looking forward, not
backward. Having said all of that, I am all for a development
model that allows us to build the core and components in either
language.
Set a goal of rewritting the JIT in
Java/C# by 2007. If IT shops are happy deploying Harmony with the
JIT
written in Java, then set a goal of rewriting 90% of the VM in
Java/C#
by 2009.
"IT shops" will judge Harmony by its performance, robustness and
completeness. I happen to believe we are going to meet those goals
better if we use Java. Again, I am all for a model that allows us
to use JITs written in C, C++ or Java.
Yes! Although it will be more challenging to create interfaces that
will work for both Java and C/C++, I suspect the end result will be
worthwhile.
As far as GC goes (arguably the most complex interface), we have
done this with MMTk & Rotor.
Modularization allows specialization. Specialization fosters faster
evolution. Harmony is an opportunity to build an infrastructure that
can outrun the existing monolithic JVM code bases. You don't need to
know the entire system to work on a given module
I could not agree more.
. A short list of JVM
modules: JIT, GC, threading/sync, class loader, verifier, OS
portablility layer. Different JITs and GCs might actually decide to
sub-modularize if they like. For example JIT "X" might have a single
high-level IR module and separate low-level modules for each
instruction set architecture supported.
I imagine that a "compiler policy" will become a (thin) module
which in turn interfaces to sub-modules which are particular
compiler instances. For example an adaptive recompilation policy
could interface to the core vm on one side, and multiple compiler
choices on the other.
Last Friday, I made the following proposal:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/
200505.mbox/[EMAIL PROTECTED]
In the context of the current discussion I'd like to re-advocate
that proposal. It is consistent with what Stefano has suggested.
To summarize:
1. Leverage existing momentum by seeding the project with two
existing VMs
2. Leverage existing work by focusing on modularity of major
reusable components (including components from outside of the seed
VMs).
3. Concurrently design new VM cores.
Modularizing the seed VMs will provide the group with a great deal
of insight into how new VM cores should be built. I say "cores"
for three reasons: a) the cores will (by defn) be small, so with a
modular framework, having multiple cores should be feasible, b)
different cores can target different needs, c) we can explore
different implementation strategies.
--Steve
