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 <[EMAIL PROTECTED]> 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 <[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/ > -- Davanum Srinivas - http://webservices.apache.org/~dims/
