harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renaud BECHADE" <renaud.bech...@numerix.com>
Subject RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Mon, 23 May 2005 01:08:50 GMT

Hi,

One possibility I see to conciliate both is to have one of the VMs to be
considered as a "bootstrap" VM (so that the one that proves the fastest to
start-up is probably the obvious choice IMHO) and the other acting like a
"high perf plug-in" for instance. I guess there will be plenty of work left
around the API implementations, anyway. (not to speak about packaging the VM
with all the tools that make it
not-a-night-mare-to-debug-and-develop-with-and-or-to-use-it. Prepackaged
J2EE, Eclipse and so one could be obvious targets)

RB

-----Original Message-----
From: Aaron Hamid [mailto:arh14@cornell.edu] 
Sent: Friday, May 20, 2005 10:58 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

As a purely idle bystander and armchair speculator, I'm with Steve on this
one.  It seems the community has roughly aggregated into "VM in Java" and
"VM in C/C++" camps.  Both camps appear to have large and robust support and
actual working implementations behind them.  In the former I see "JikesRVM"
and "JNode".  I think the Java-in-Java horse has been beaten to death and
hopefully we can agree that it is not only feasible, but works today and
brings its own set of benefits.  Likewise in the "VM in C/C++" camp there is
GCJ "and friends" (which already have a long track record and fresh ideas,
and amicability with large established GNU projects), as well as some
respectable independent offers such as JCVM and MudgeVM.

Instead of shoehorning the two camps into one VM, how about accepting, for
the meantime, two somewhat independent lines of /investigation/.  I have
doubts that a "universal framework interface" could be applied to both
implementations without lots of pain and impedence mismatch (especially the
boundary-crossing-problem), but I am sure that each can take what is
applicable from the other without having the other's set of interfaces
forced on them.

In the end, it might turn out to be useful to have two independent
implementations, possibly front-ended by a, um, front-end.  I imagine the
"VM in C/C++" may have characteristics that make it more amenable to
low-latency desktop use, while the "VM in Java" may have throughput
characteristics that make it more amenable to server side use (again, wild
speculation on my part).

Since it is (at least to me) entirely non-obvious yet what the ultimate
architecture should be, why not just let two investigations proceed in
parallel with those parties interested in the respective technologies
participating under the umbrella of "harmony" instead of being shut out
because they happen not to prefer the language or architecture that has been
pre-emptively mandated.

Aaron

Nick Lothian wrote:
>>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
>>
>>
> 
> 
> +1
> 
> After looking through the code of Jikes I'm voting for this proposal
> (and the use of Jikes as a seed VM) because 
> a) Jikes seems a fairly mature, and it appears somewhat modular already
> b) I am (much) more likely to be able to contribute to Jikes than a
> C-based VM
> 
> I do have some concerns about the build process that Jikes currently
> has, but Steve has already spoken about addressing that.
> 
> There are probably licence issues that would need resolving, too.
> 
> This isn't meant as a negative vote against other VMs - Steve's proposal
> explicitly mentions working on other VMs in parrel. 
> 
> If people were going to work on JCVM (for instance) then I would imagine
> some enhancements could be shared, particularly to the parts of JCVM
> written in Java. It would also enable us to understand the interface
> requirements between parts of the VM better than most of us currently
> do.
> 
> Nick
> 
> 
> IMPORTANT: This e-mail, including any attachments, may contain private or
confidential information. If you think you may not be the intended
recipient, or if you have received this e-mail in error, please contact the
sender immediately and delete all copies of this e-mail. If you are not the
intended recipient, you must not reproduce any part of this e-mail or
disclose its contents to any other party.
> This email represents the views of the individual sender, which do not
necessarily reflect those of education.au limited except where the sender
expressly states otherwise.
> It is your responsibility to scan this email and any files transmitted
with it for viruses or any other defects.
> education.au limited will not be liable for any loss, damage or
consequence caused directly or indirectly by this email. 


Mime
View raw message