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: [arch] The Third Way : C/C++ and Java and lets go forward
Date Tue, 24 May 2005 01:42:47 GMT

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 Magnusson Jr                                  +1-203-665-6437

View raw message