harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: [arch] The Third Way : C/C++ and Java and lets go forward
Date Tue, 24 May 2005 02:31:37 GMT
Peter Donald wrote:

> Hi,
> Steve Blackburn wrote:
>>> Lets get moving.  Comments? 
>> Respectfully, I think this would be a mistake.  I think it would be a 
>> major error to start coding a VM core until there was more clarity 
>> about what we are doing and what the core would require.
> You could be right in that it is a "technical" mistake but in the long 
> wrong it may prove not to be useful for helping to kick start

erg ... should be

...but in the long wrong it may prove to be useful for helping to kick 

> the community and thus not a "community" mistake. Discussion about 
> abstract concepts and implementation strategies with no concrete code 
> that people can look at and play with can lead to never ending 
> discussions that never seem to progress. Give people some code and 
> some leeway to experiment for themselves and they are much more 
> likely  to come around to understanding the problem and thus being 
> able to agree on a way forward. Paraphrasing what was said earlier in 
> this mailing list "crap code and good ideas will lead to a good 
> community while other combinations may not".
> Experimenting with a codebase will at least give people a feel for 
> other members of the community and how they cut code. This will be 
> worth it even if the entire codebase gets thrown out or rewritten from 
> scratch. Some of the people here are unlikely to be swayed from "C/C++ 
> for VM" crowd  with just words - code which they can profile and 
> generate performance statistics with is much more likely to convince 
> them. Don't get me wrong - discussion is good and you have convinced 
> me (who was firmly in the "C for VM" camp) that Java In Java is a good 
> approach - I would love to hear more about it (especially how 
> synchronization, volatile and monitors could be plugged in) but there 
> has been enough talk and probably a good time for action to start ;)
> So I agree with you that this move may be a "technical mistake" but I 
> would put forth the idea that it may be a bigger "community mistake" 
> if something concrete does not start soon. FWIW I am not involved with 
> Apache or any of the VM/Classpath projects but I suspect that this is 
> a way forward that would be useful using the "Apache way".
>> When a VM is built in Java, the only need for C/C++ is for direct 
>> interaction with the OS (one modest file of C code with interfaces to 
>> the most basic OS functionality), and for bootstrapping (another 
>> OS-specific file of C code plus about a dozen of lines of assembler).
> I guess I was under the wrong impression aswell. I thought that JRVM 
> required another JVM during build to compile its own codebase and 
> create an executable image. JRVM would then use this image during its 
> execution. Could we use a simple interpreter for this initial stage? 
> Or am I completely off base.
>> I am very excited about all of the technology that this project is 
>> bringing out.  I think JamVM looks outstanding, but I think it would 
>> be a serious error to take it as the core for Harmony.  It was not 
>> *designed* with our goals in mind.  We need to understand where the 
>> value in JamVM (and all other candidates) is, and then maximize our 
>> leverage on that in the Harmony VM, whether it be through an entire 
>> VM (unlikely), components (I hope so), designs (I am sure), or 
>> mechanisms (certainly).
> I don't disagree with you but I guess I think it would be more useful 
> to place community "correctnes" over technical "correctnes" at the 
> begining. Once a group is working together they should be able to 
> migrate to JRVM or whatever could be used as the bases.
> -- 
> Cheers,
> Peter Donald
> "The only way to get rid of a temptation is
> to yield to it." - Oscar Wilde (1854-1900)

View raw message