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 > >