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
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.
--
Cheers,
Peter Donald
"The only way to get rid of a temptation is
to yield to it." - Oscar Wilde (1854-1900)
