harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: Developing Harmony
Date Mon, 16 May 2005 21:10:09 GMT
A quick recap on key points from my original post (below):

. Focus on componentization
. Use one or two existing VMs to bootstrap and drive effort to componentize
. Concurrently develop new cores

As far as I can tell the goal of componentization is widely accepted.

I view the VM core as another component, one of the simplest, but most 
design critical.  The model of componentization allows any component to 
be written in whatever language makes most sense.

For the sake of momentum I advocate concurrently pushing 
componentization in one or more existing VM cores while developing new 

In my experience our biggest challenge is going to be in getting 
componentization to work.  We've pushed this hard with MMTk (getting it 
to plug into multiple VMs, across language boundaries), and since the MM 
is probably the most intricately connected component, that gives us hope. 

You may find it interesting to read the writeup of the ORP team's effort 
to port their GC & JIT to Rotor 

> I'm pretty sure we want a framework in C/C++, whatever components are 
> developed in.

Umm.  Why?


My original post....

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
        - 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, 
   . Work concurrently with above work on components in old core/s,
     miminize loss of momentum, try to really think it through
   . 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!



View raw message