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: [modules] classloader/jit interface
Date Sun, 26 Jun 2005 12:44:35 GMT
Hi Rafal,

My guess is that there are a dozen people on this list right now who, 
given a month, could build a simple VM from scratch, on their own.  
However, building something like ORP or Jikes RVM is an enormous task, 
well beyond the scope of any individual.

In other words, I don't think the challenge we collectively face is that 
of identifying the right abstractions for a simple VM---this is 
relatively simple.   My feeling is that the real task in front of us is 
designing and implementing a VM core which can support the ambitious 
goals of Harmony---this is a challenge.

As I've said in previous posts, I think that looking at clean, simple 
VMs such as Jam VM will be invaluable to this project.

However, clean abstractions made in the context of a simple VM goes to 
pieces once the complexities of aggressive optimizations and pluggable 
generality come into the picture.  A great example of this is the 
hardness of retrofitting GC maps into a VM.  GC maps are essential to 
high performance GC, but are often overlooked in simple VM designs and 
yet retro designing them is an enormous task.  Likewise object model 
optimizations, method dispatch, stack frame organization, etc etc all 
wreak havoc on more basic abstractions.

I don't think we're that far away from being able to build a new VM 
core.  We have so much at the table.  My hope is that we could have our 
own VM core with a simple interpreter or JIT and perhaps a naive GC 
could be up and working in a matter of months. I am also a strong 
believer in being prepared to throw early implementations away.  If we 
try to get our first implementation perfect first shot, we're sure never 
to have a first implementation.  On the other hand, we should certainly 
try to make the most of the experience we do have at hand, so that our 
first implementation is not too wildly off the mark.

A few more detailed responses:

>- it is important to distinct between innovation/research and good
>engineering.(eg mono
Innovation/research and good engineering are absolutely not in 
opposition!!  Good engineering is KEY to good research.

> well engineered framework
>shall make research easier after all; that is why I'm rather a
What is the connection between good engineering and the use of C?  I 
don't follow.

>make sure to make it efficient as some operations (write
>barriers, for example) are critical when it comes to performance;
Please see previous posts on this subject.  Fast barriers probably need 
to be written in Java or compiler IR, not C (this is because they are 
injected into user code and need to be optimized in context).

>- avoid prematurely sacrificing design for the sake of performance;
Agree 100%

>- Java-C/C-Java (internal) interface doesn't necessarily have to be
Anything that involves a function call is "slow" in the context of many 
aspects of VM implementation.  This is fine for coarse grained 
interfaces, but unacceptable for fine grained interfaces such as the 
allocation and barrier paths.  Careful design should make the 
integration of C & Java modules possible (just avoid interface 
transitions on the fast path).

>- having some kind of 'frankenVM' consisting of various pieces doesn't
>have to be inherently bad; did Mono emerge this way or am I wrong ?
A VM that draws on the enormous investment at hand by taking a JIT from 
here and a memory manager from there is a very wise choice.

>- someone has to build a 'big picture' and split it into parts to make
>people working on details (don't start with one or two interfaces,
>start with a big picture first: several main modules, how shall they
>interact with other modules, where are potential problems); that HAS
>to be done by a person with extensive experience in VM construction
>(engineer rather than researcher); newbies like myself fall short in
>this mainly because of not having dealt with details;
I agree with this very strongly, however I don't think it should be one 
person---it should be done collectively.

>- sorry for being a bit offensive on researchers ;) it wasn't my
>intention, I just think that we need to have a proven set of things
>first, then may do some good research on it;
OK.  I'm offended ;-) 

In all seriousness, you need to understand that the state of the art in 
VM design and implementation is coming out of researchers and research 
labs.  Research and proven results are not and must not be mutually 
exclusive.  To the contrary!  As far as I know, as far as "proven" 
results go, the two best performing open VMs are ORP and Jikes RVM, both 
of which have come out of research labs.  Good engineering is at the 
heart of good research---I believe the opposite to be true too.


View raw message