Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <428439D6.5080709@anu.edu.au>
Date: Fri, 13 May 2005 15:23:34 +1000
From: Steve Blackburn <Steve.Blackburn@anu.edu.au>
Reply-To: Steve.Blackburn@anu.edu.au
Organization: Australian National University
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Developing Harmony
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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