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. > > 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. > > 2) create some internal (and friendly!) competition on speed and > compliance :-) Good idea. > > 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. > > 4) allow compensation (easier to experiment in java than in C, harder > to port java than C) > > Thoughts? > > -- > Stefano. > >
