I think the term "battle tested for building OS and
compiler systems" puts good words to my thoughts on
why the cornerstone of Harmony should be written this
way. My earlier comment said as much, and to add in
Java-written class libraries, etc. Whatever path that
may take, starting with a C/C++ JVM will most certainly
draw upon the strengths of C/C++.
A phased approach like Weldon describes will provide
all of us with some semblance of a psychology of
progress as the project matures. Build one piece,
test it, build the next, etc. Two years to get to
a JIT compiled JVM runtime environment is somewhat
reasonable, especially given the ASF culture.
Everyone who uses software is accustomed to announcements
of both major and minor updates and, given proper attention
to the sequence of development for each component, Harmony
could receive a warm welcome as it develops each stage.
We don't have to eat the whole pie at once, and we don't have
to. How about the general proposal as shown here and in
recent postings of:
- FIRST: A basic JVM, written in C/C++, by some combination
of contribution, new development, and extension
- SECOND: JIT and/or other compile optimizations, still C/C++
- THIRD: Other JVM speedups, in concert or concurrently
with a JIT compiler, still C/C++.
- FOURTH: Potential rewrite of key portions into Java.
This process will certainly take several years, but the
advantage to this is an accumulation of experience on
what works and what does not work, especially for the
various runtime and compile optimizations.
Comments?
Dan Lydick
> [Original Message]
> From: Weldon Washburn <[EMAIL PROTECTED]>
> To: <harmony-dev@incubator.apache.org>
> Date: 5/20/05 1:07:58 AM
> Subject: Re: [arch] VM Candidate : JikesRVM
http://jikesrvm.sourceforge.net/
>
> 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. 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. 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.
>
> >=20
> > 1) the goal of making things modular enough to allow to swap things
> > around and allow parallel development
> 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.
> >=20
> > 2) create some internal (and friendly!) competition on speed and
> > compliance :-)=20
> Good idea.
> >=20
> > 3) attract two different pools of talents
> 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. 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.
> >=20
> > 4) allow compensation (easier to experiment in java than in C, harder
> > to port java than C)
> >=20
> > Thoughts?
> >=20
> > --
> > Stefano.
> >=20
> >
