Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <19e0530f05052318542b11e1a7@mail.gmail.com>
References: <C64A85F5-45BC-4388-9C4E-91D5542858E6@apache.org>
 <6321D59D-3243-4CFF-90F5-AAE609B5C094@apache.org>
 <42922951.6050805@dellroad.org>
 <89C6EA09-7FB5-4491-B902-05D977364707@apache.org>
 <4292741A.4020602@anu.edu.au> <19e0530f05052318542b11e1a7@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <43C54572-C796-4D35-8776-FFF8CD2415CA@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: [arch] The Third Way : C/C++ and Java and lets go forward
Date: Mon, 23 May 2005 22:32:03 -0400
To: harmony-dev@incubator.apache.org


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