Added your thoughts to wiki - http://wiki.apache.org/harmony
thanks, dims On 5/13/05, Steve Blackburn <[EMAIL PROTECTED]> 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/
