harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Hamid <ar...@cornell.edu>
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Fri, 20 May 2005 15:12:42 GMT
My point was that instead of attempting to disenfranchise one or the other camp of its notions,
allow two parallel veins of investigation according each his own inclination.  I _wholeheartedly_
agree that work can begin *now* on any single or multiple (hopefully no more than two, according
to the aforementioned groups?) proposed VMs.  I just don't think it's practical to dictate
one, and then attempt to convince the other camp that they should work on the other's VM.

As far as coding from the ground up: it can be done, but I presume investigating existing
VMs first, or again, in parallel, would nevertheless still be worthwhile.

Similarly one can "wait" for a corporate donation, but there are those who want to do something
now, and instead of waiting they can surely start on /something/, even if some mana does eventually
fall from the heavens.

So I don't see the latter two scenarios as mutually exclusive with the former.

Aaron

acoliver@apache.org wrote:
> 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. 

Mime
View raw message