On May 23, 2005, at 8:23 PM, 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.
I sort of agree. It's clear we need more clarity about
modularization (hint, hint) and that we need to be going on that
(hint, hint), but I would be dollars to donuts that you could frame
out a simple high level modular structure that we could start
refactoring a donated core from the beginning to start playing. I
want to see people get their hands on showing how a VM core can be
comprised of Java and C++.
Also, I would bet that you could give us a laundry list of core
kernel intrinsic APIs that we'd need to develop/refactor/import/etc
for the Java pieces of the VM.
but rather my understanding that we'll need a small C/C++ kernel
to host the modules, no matter how they are written, and this is
a way to get that going...
This is not the case Geir.
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). That's it. The kernel of the VM can be entirely
written in Java. Whether or not we chose to do that is another
matter, but your comment above is technically incorrect, and
therefore should not be the basis on which we start coding.
Maybe we're just having a semantic problem - I would consider the
bootstrap part and the OS interaction part the kernel, and probably
some non-OS pieces like helping out w/ memory management - letting
the java work with raw pointers. There may be other pieces that you
consider kernel that are in Java, and I'm fine with that.
Please, just tell us what they are.
This misconception highlights why it is that I think we need a
seeding process to gain some collective understanding before we
start cutting code for a new VM core. This requires some patience
but I think will make the difference between us producing a)
something that is free, runs OK, and is portable, from b) something
that leverages the outstanding collective pool of ideas at the
table (ovm, gcj, kaffe, joeq, jamvm, jc, orp, mudgevm, jikesrvm,
etc etc) to deliver what I think could be the best performing, most
exciting VM, free or non-free.
define "free". It has many meanings around here ;)
Yes, this is just the seeding process given a kick. You want to show
up with JikesRVM for the core functionality, I will do everything I
can to help you get the paperwork done. But will need the "direct
interaction" code, and the bootstraping code, and starting w/ a small
existing project to help us on our way is all I was doing.
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.
That wasn't the intention, in that it's not the core as a VM, but
core as the kernel that we need for the modules, which may or may not
be in Java. I understand that there will be parts that will be best
done in Java - I'm all for it.
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 understand that it is important that we seize the enthusiasm of
the list and start working, but respectfully, I think that cutting
code for a VM kernel right now would be a bad mistake, one that
might be gratifying in the short term but that is likely to lay the
wrong foundation for what I think may become the most exciting VM
project yet.
We're not pouring cement and bending re-bar here. I'd be happy to
abandon anything we start with once we figure out what is better, or
if some other donation that more fits our intended design comes along.
I'm 100% against looking around at parts, and cobbling something
together. I'm 100% for having parts to play with our ideas, but
setting out an architecture and roadmap that we design, we decide on,
and then we instantiate via fresh code, donation or other.
So that said, are you still so against it?
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
