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 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.
I very much resonate with Peter. Peter and I (and Leo) have scars all over out virtual bodies for the years of journey in Apache Avalon, where we traded "architectural correctness" over "community wisdom". Failing miserably. The Avalon Project went down in flames. The simple technical disagreements became poisonous (and clever) personal attacks, in order to undermine the technical opponents and convince the community of the value of their position. Experienced Apache members and board directors spent years dealing with the social fallout of that project. It took 2 years for the ASF to kill avalon. If you ask all the participants, they will never go back. They know now how to accept disagreement, but more, how the 'perfect architecture' is a holy grail. Do the simplest thing that can possibly work for you and move on, the community is an incredibly powerful engine, it's better to learn how to use it than not. Now Avalon is dead and nobody is missing it. For a lot of us, it's a monument to the death of the old software engineering school applied to open development. A mythical land. A place that so many want to see existing that are willing to sacrifice a lot for it... but it nevertheless can't be reached, just like the real Avalon, King Arthur's tomb. I am the one who proposed Avalon, in 1998, with the intention of creating a 'kernel' for servers (before OSGi, before jboss mbeans, before geronimo's mbeans). I am the one who worked thru to kill it: despite the great deal of technological advancement that was created in that project, the social poison was too much to handle for the rest of the foundation, it required more energy to control/watch than it produced for the foundation. And this is not something we can tollerate, if we want to continue to scale. [This is also something that the incubator won't tollerate, if we reach that stage] To cut it short: we need a way to move forward, I agree with that. But let's try to keep it flexible and try things out, things don't have to be carved in stone as you start. I will not stop repeating it: do the simplest thing that can possibly work. There is a lot of energy on this mail list, let's not force everybody to agree on something (either architecture, languages or licensing) but let's draw simple enough lines in the wiki sand, so that people can start putting, independently, their pieces together and experiment. Collaboration will happen when it makes sense, not when it is imposed. Allow Darwin to play in your sandbox and he will take care of finding the right architecture, one step at a time. -- Stefano.
