harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: [arch] The Third Way : C/C++ and Java and lets go forward
Date Tue, 24 May 2005 00:23:54 GMT
> 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 

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.


View raw message