harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Two seeds (Re: Developing Harmony)
Date Fri, 13 May 2005 17:08:51 GMT
oops. operator error
(https://svn.sable.mcgill.ca/wsvn/sable/?rev=1732&sc=1) threw me off.
SableVM does not use MMTk. But still....

-- dims

On 5/13/05, Davanum Srinivas <davanum@gmail.com> wrote:
> 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/
> 


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

Mime
View raw message