Weldon Washburn wrote:
On 5/19/05, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: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.
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.
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.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"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.
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.
Yes! Although it will be more challenging to create interfaces thatAs far as GC goes (arguably the most complex interface), we have done this with MMTk & Rotor.
will work for both Java and C/C++, I suspect the end result will be
worthwhile.
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 JVMI 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.
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.
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
