Panagiotis, MMTk is being used in SableVM (i think!)
-- dims On 5/13/05, Panagiotis Astithas <[EMAIL PROTECTED]> wrote: > Steve Blackburn 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 > > Could we interpret this as a positive response to Davanum Srinivas's > request for a JVM donation to the project? > > > b) Another very different VM (kaffe?) > > . amenable to modularization > > . amenable to other components (drop in MMTk?) > > Of all the options presented so far, what I find most appealing is the > combination of a VM in Java (like JikesRVM) and a WAT approach like gcj > or jcvm. In a sense that Harmony could enable either usage scenario, > more or less like gcj does now. Would you think that MMTk could be used > in say jcvm? Archie, would that make sense? > > > 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 > > Cheers, > > Panagiotis > > -- > Panagiotis Astithas > EBS, Electronic Business Systems Ltd. > 18 Evgenidou Street, 115 25, Athens GREECE > Phone: +30 210 674 7631 > Fax: +30 210 674 7601 > http://www.ebs.gr > -- Davanum Srinivas - http://webservices.apache.org/~dims/
