harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Two seeds (Re: Developing Harmony)
Date Fri, 13 May 2005 11:24:34 GMT
Steve,

This is great!!! I love the idea of using JikesRVM and one another JVM
(hey SableVM already uses MMTk, Kaffe's license is too difficult -
though not impossible - to change because TransVirtual is no more).

thanks,
dims

On 5/13/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
> I am going to stick my neck out and make a few concrete suggestions
> for how the Harmony VM might be developed.
> 
> A few motivating goals:
> 
>   o Focus on modular, interchangeable components
>     - exploit existing compilers, memory managers etc
>     - promote configurability (different components for different contexts)
>     - allow diversity in development approaches
>     - encourage large-scale contributions (here's a compiler)
> 
>   o Bootstrap the project rapidly
>     - capture momentum
>     - seed the project with an existing VM-core (or cores)
> 
>   o Design a clean core (or cores) from scratch
>     - do this concurrently with work on components in existing core/s
>     - the core should be lightweight
>     - multiple cores may make sense
>       - the needs of different contexts may require this
>       - competing approaches may be healthy
> 
> A concrete option:
> 
>  1. Use two VMs as seeds
>     a) Jikes RVM is a possible candidate
>        . Focus energy on cleaning it up and modularizing it. This is
>          something we've already begun (see earlier post), but will
>          take a lot of work.
>          + Get a very good optimizing compiler
>          + Get an efficient and modular memory management toolkit
>            (MMTk)
>          - Need to deal with licensing issues and gain the consent of
>            the community (not insurmountable)
>          - Need hard work to achieve modularity goal for whole VM
> 
>     b) Another very different VM (kaffe?)
>       . amenable to modularization
>       . amenable to other components (drop in MMTk?)
> 
>  2. Leverage extensive experience to build new core/s
>     . Start with a clean slate
>     . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
> jnode,...)
>     . Work concurrently with above work on components in old core/s,
>       miminize loss of momentum, try to really think it through
>       carefully.
>     . May be sensible to develop more than one core
> 
>  3. Develop new components
>     . Extract components from existing work, apply to new VM/s
>     . Develop new components from scratch
>     . Encourage porting of existing compilers etc into this framework
> 
> 
> Alternative options:
> 
>   o Start with just one seed
> 
>   o There are many different ways... the above is indicative, not exclusive
> 
> 
> OK.  So I've stuck my neck out.  The above is vague and very
> ambitious, but those rough thoughts come out of a lot of experience
> with VM design---not just mine but the experience of those who I've
> been discussing this with and working with.  A component based VM is
> not trivial at all.  I've not mentioned any of the vast complexity
> that lies within a real VM.  However, my experience with porting MMTk
> across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
> working on porting to jnode--Java) gives me hope!
> 
> Cheers,
> 
> --Steve
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message