harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Bootstrapping community (Re: [arch] The Third Way : C/C++ and Java and lets go forward)
Date Tue, 24 May 2005 03:33:17 GMT

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. <geirm@apache.org> 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 <Steve.Blackburn@anu.edu.au> 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
>> geirm@apache.org
>>
>>
>>
>>
>
>
> -- 
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message