harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Lydick" <dlyd...@earthlink.net>
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Sun, 22 May 2005 16:32:31 GMT



> [Original Message]
> From: Steve Blackburn <Steve.Blackburn@anu.edu.au>
> To: <harmony-dev@incubator.apache.org>
> Date: 5/20/05 2:03:30 AM
> Subject: Re: [arch] VM Candidate : JikesRVM
http://jikesrvm.sourceforge.net/
>
> 
... snip ...
> 
> Last Friday, I made the following proposal:
> 
>
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/%
3c428439D6.5080709@anu.edu.au%3e
> 
> In the context of the current discussion I'd like to re-advocate that 
> proposal.  It is consistent with what Stefano has suggested.
> 
> To summarize:
> 
> 1. Leverage existing momentum by seeding the project with two existing VMs
> 2. Leverage existing work by focusing on modularity of major reusable 
> components (including components from outside of the seed VMs).
> 3. Concurrently design new VM cores.
> 
> Modularizing the seed VMs will provide the group with a great deal of 
> insight into how new VM cores should be built.  I say "cores" for three 
> reasons: a) the cores will (by defn) be small, so with a modular 
> framework, having multiple cores should be feasible, b) different cores 
> can target different needs, c) we can explore different implementation 
> strategies.
> 
> --Steve
> 
> 

What I hear in this proposal for multiple VM's is the potential for

 1. munge-and-squash to create a new VM based on the
    best qualities of the seeded contributions.

 2. divide-and-specialize to take these cores and build
    some derived VM's that specialize in specific feature
    sets, such as a cornerstone for large J2EE app servers,
    small mobile environments, fast-starting J2SE programs,
    high-resource J2SE programs and similar conflicting
    runtime matters.

 3. Useful combinations of the above.

By possibly following combinations of both approaches, then
taking the lessons learned, then potentially a single VM
or selected subset of multiple VM's would emerge, all based
on the best of the batch of experiments, and made available
either at compile time (multiple VM binary program names),
or at runtime (single binary, multiple startup options).

Is this reasonable?  Am I reading Weldon and Steve correctly?



Dan Lydick




Mime
View raw message