harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricky Clarkson <ricky.clark...@gmail.com>
Subject Re: Developing Harmony
Date Tue, 17 May 2005 12:20:14 GMT
Do we need the extra features of C++ for the low-level stuff that
Harmony needs to do?  Java can provide the OO wrappers around things,
we don't need Java wrappers around C++ classes around C functions..

I don't think there's enough gain in using C++ to warrant the extra
complexity in its use.  But that's just me.

On 16/05/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
> 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
> cores.
> 
> 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
> (http://www.jot.fm/issues/issue_2004_10/article3/index_html).
> 
> > I'm pretty sure we want a framework in C/C++, whatever components are
> > developed in.
> 
> Umm.  Why?
> 
> --Steve
> 
> 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
>           (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
>

Mime
View raw message