On May 23, 2005, at 11:03 PM, Davanum Srinivas wrote:
Geir,
Am not sure u understood where i am coming from. (I feel that u saying
that we are not going to get commit privs for folks interested till
the design discussions are over AND that design decisions are going to
be made on the mailing list ONLY?)
Huh? I don't understand that.
What I want to do is start getting people working and committing, but
*also* getting some of the sophisticated design work done. I think
that we can drive one from another and vice-versa. By having a
little kernel-thingy (I won't call it "core" because after talking to
Steve, it's clearly a matter of semantics) that's for our
prototyping and learning, we can start working with the
modularization, which as I understand it, is a current topic in VM
research.
Yes, I'm hoping the design decisions are made on the list, btw. :)
I have trouble keeping up with the mailing list and so do others...am
not saying that we have to check-in code from all the seed VM's into
our repo. I want to keep the momentum going by getting committers on
board, letting them share thoughts, documents and code if any (SVN
repo?), may be use JIRA to document requirements etc. Right now no one
knows who is going to be working and on what and how to contribute
etc.
Yes - that's the entire point of what I'm trying to do :)
As stefano says - "good ideas and bad code build communities, the
other three combinations do not"....Let's build the community without
waiting for the discussion to end on the mailing lists and let the
committers/community decide on how best to move forward. We don't
(mentors) have to pick the "winner"? do we?
There's no "winner". LIke I said, this isn't about blessing one
thing as the solution.
We aren't going to just take something from outside and say "done".
What I wanted is code to experiment with and adapt to what *we*
design. We can add things from elsewhere as the design require (like
modularize parts of JikesRVM, which I understand needs to be done...).
Look at Jam. My understanding is that it sorta works, and it's very
simple. It sounds like it's easy to refactor to a small, kernel-
thingy that will be a basis of support for moving forward w/ the
modularity. And then we can throw it out :) or not. Whatever we
discover. I think we're going to learn a lot here.
geir
(And while I'm a mentor, I'm also a participant :)
Thanks,
dims
On 5/23/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On May 23, 2005, at 9:54 PM, Davanum Srinivas wrote:
Geir,
Am convinced that we can write a JVM in pure java with minimal C/C
++.
Why? If it has C/C++, it's not pure Java. Period.
This isn't about whether or not that it can be done in Java, or a way
to get it into C/C++. Lets get over that misconception right now.
I'm sure that major parts can be done in Java - it's been
demonstrated by JikesRVM, and lots of experienced VM people point in
that direction, even with a C/C++ core. I have no problem with that.
How about we poll the VM candidates on who wants to help seed the
project, ask them to do the paperwork, then we can get folks on
board
as committers and let them play in sandboxes (see below). Folks
who do
the work will then get to decide the future direction. We don't have
to make the technical decision now before the committers are on
board.
What do you think?
I don't see what we gain. We want to create *our design*, not make
"frankenVM". The point of starting with a small seed C/C++ kernel is
to get the bootstrap and intrinsics support that *any* VM will need,
pure C, pure Java, or mixed.
Our discussions will point to where we have to refactor.
On top of that, we build what we decide to build, not what we find
out there, unless what we find out there is what we designed for.
geir
Steve,
As a mentor, i agree with you whole heartedly. How do we go about
this
process of designing the core for harmony? Could we say strip
down say
JamVM/JCVM to create a bootstrapper (OS dependent stuff ONLY) for a
stripped down JikesRVM in our sandbox to illustrate the validity of
writing the "almost" the whole JVM in java? [Nothing like working
code
to get juices flowing]. My problem is that i haven't done this
(writing a JVM) before, so am itching to do something that will help
me understand better the problems/challenges involved and help me on
deciding what to look for in the other existing VM's that we can
leverage/use.
Thanks,
dims
On 5/23/05, Steve Blackburn <[EMAIL PROTECTED]> 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.
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.
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.
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 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.
--Steve
--
Davanum Srinivas - http://webservices.apache.org/~dims/
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
--
Davanum Srinivas - http://webservices.apache.org/~dims/
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
