harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Blake <craigwbl...@mac.com>
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Fri, 20 May 2005 15:21:47 GMT
Symbolic +1

Sounds like the way to go.

Craig

On May 20, 2005, at 12:01 AM, Steve Blackburn wrote:

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