harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Panagiotis Astithas <p...@ebs.gr>
Subject Re: Developing Harmony
Date Fri, 13 May 2005 10:11:48 GMT
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)
>  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

Could we interpret this as a positive response to Davanum Srinivas's 
request for a JVM donation to the project?

>    b) Another very different VM (kaffe?)
>      . amenable to modularization
>      . amenable to other components (drop in MMTk?)

Of all the options presented so far, what I find most appealing is the 
combination of a VM in Java (like JikesRVM) and a WAT approach like gcj 
or jcvm. In a sense that Harmony could enable either usage scenario, 
more or less like gcj does now. Would you think that MMTk could be used 
in say jcvm? Archie, would that make sense?

> 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



Panagiotis Astithas
EBS, Electronic Business Systems Ltd.
18 Evgenidou Street, 115 25, Athens GREECE
Phone: +30 210 674 7631
Fax: +30 210 674 7601

View raw message