harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Developing Harmony
Date Mon, 16 May 2005 15:03:53 GMT

On May 13, 2005, at 1:23 AM, Steve Blackburn 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)

Yes - that was the goal :)

>  o Bootstrap the project rapidly
>    - capture momentum
>    - seed the project with an existing VM-core (or cores)
>

That too :)

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

Agreed.  I'd like to see us start with *one* donation from someone  
that won't mind us kicking it around and deciding what's wrong :) and  
examining all the other VMs that we can.  THen we either fix (because  
I'm really lazy), or start again based on what we've learned from all  
the others..

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

Well, Kaffe is certainly something we want to study and learn from,  
but I'm not sure we can start with it - it's already a separate,  
healthy project elsewhere!

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

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message