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:24:28 GMT

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 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.


Peter Donald
"The only way to get rid of a temptation is
to yield to it." - Oscar Wilde (1854-1900)

View raw message