harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Fri, 20 May 2005 07:01:58 GMT

Weldon Washburn wrote:

>On 5/19/05, Stefano Mazzocchi <stefano@apache.org> 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/%3c428439D6.5080709@anu.edu.au%3e

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



Mime
View raw message