harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoli...@apache.org
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Fri, 20 May 2005 14:49:55 GMT
acoliver@apache.org wrote:
> I disagree with the permise of what you are saying.  Let me say "the 
> wrong thing"
> 1. There are no open source virtual machines that are presently 
> practical to run high volume production code (yes I know you all run 
> kaffe whatever for XYZ and love it to death, but I mean non-entusiasts 
> would run it too).
> 2. There are no Java virtual machines period that are presently 
> practical to run high volume production code.

I meant Java virtual machines written in Java...  sorry

> Language at some level is basically irrelevant but the VM will be to at 
> least some level native code.  It has not yet been demonstrated that a 
> high performance optimizing runtime compiler (one that is competitive 
> with production grade VMs) can be built in Java.
> At present there is more of a divide between people who are interested 
> in what is theoretically possible and "forward looking" (which I think 
> buys into Java marketing just a bit too much) and those who are merely 
> interested in the more practical aspect of a high performance open 
> source VM.
> More or less I am not sure that both camps will be satisfiable with one 
> code base though a modular approach might make this possible.  This may 
> give into Conway's law just a little too early (not modularity which is 
> just good practice but the division of modules ;-) ).
> There are also other divisions within our group which must find 
> compromise, consensus or atrophy.  There are those who want to pick one 
> of the existing open source projects and seed the projece.  There are 
> those who want to code from the ground up (some completely including the 
> API).  There are those who want to wait or pray for a corporate donation.
> I suggest this present-minded compromise.  Work can begin *now* on a 
> small modular native-code portable (macro/micro/)kernel.  I would 
> suggest that it is most practical to do in C (because of cross 
> compilation and portability).  I would suggest that it not be done in 
> C++ (because it would not be wise to deal with the name mangling/etc 
> issues at this level, although I kind of think C++ may be a better 
> solution for the higher levels above).
> I will start:
> #include<stdio.h>
> main () {
>   printf("Harmony JVM version .001\n");
> }
> That is only a start.  We can build a layer for plugging in a 
> bootstrapper for Java code for those who want to code an interpreter in 
> Java.  We can code a layer for plugging in a primordial classloader 
> written in C/C++ or Java.  We can code a bytecode interpreter.
> Should donations or code that can be reused be discovered, we can base 
> said modules on such code.  Open source software darwinism will take 
> care of most of the other decisions for us.
> -Andy
> Aaron Hamid wrote:
>> 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. 
>> .

Andrew C. Oliver
SuperLink Software, Inc.

Java to Excel using POI
Commercial support including features added/implemented, bugs fixed.

View raw message