On May 23, 2005, at 10:31 PM, Peter Donald wrote:
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...
I still have no clue what "long wrong" means. Try again? :)
geir
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)
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
