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 21:15:14 GMT
Hi Rob,

We'd obviously be shooting ourselves in the foot if we did not make the 
most of JamVM...

>However, I'm probably one of the few people who has written a
>non-trivial VM from scratch, and when I started I already was an
>experienced VM engineer.  So my thoughts may be useful/interesting or
>annoying.
>  
>
Useful.

>First of all, just because JamVM is small does not mean it is trivial.
> As I was interested in targetting embedded platforms, I put in a
>large amount of design effort _from the start_ to minimise code size
>and runtime memory usage.
>
The goals of harmony are broader, but this is just where we are right 
now---trying to get rolling on the up-front design effort.

>  As in many other situations, smallness can
>come from triviality or from careful design.  Of course, many parts of
>JamVM are simplistic, but if code size == quality we'd all be using
>Microsoft Windows.  It is the last trap I would have thought
>open-source people would fall into.
>
I think often they do, but I sure hope we're not going to go down that path.

>The interpreter in particular I like to think of as
>"state-of-the-art".  It is certainly not trivial, and it is more
>optimised than most commercial VM interpreters (in many tests it is 2x
>faster than HotSpots' interpreter under Mac OS X).  This in itself has
>taken many months of work, and I have substantially rewritten it
>twice, so it is two iterations beyond my first interpreter, which also
>included several advanced techniques.  It now does direct-threading,
>static and dynamic stack-caching, prefetching and makes use of
>super-instructions.
>  
>
The obvious question is how Harmony can use this experience?  Can we 
take JamVM in its entireity as our starting point?  (I'm not in favour 
of us doing this with JamVM or any other VM)  Can we take the 
interpreter as a module?  Can we use the interpreter as the template for 
a new one?

>One of the advantages of being a "one man team" is that you know the
>code intimately.  While this can lead to spaghetti-like code with many
>inter-module dependencies if you're not careful, it can also lead to
>compact code, as you're not afraid to re-factor modules and their
>interfaces when the time is right.
>
I agree.  However a VM on the scale that Harmony aspires to is well 
beyond the scope of a single person.  The complexity of a production 
quality JIT is itself beyond the scope of a single person.  While I 
think it is an error to overstate the difficulty of the problem, it is 
also a mistake to not realize that VMs of the scope we're aiming to 
compete against have been developed over a number of years by fairly 
large teams.

>  Having modules written by separate
>teams can result in in-efficiency and code duplication, as each module
>implements its own utilities, e.g. hash tables, lists, etc., or ends
>up marshalling arguments for an inappropriate interface.
>
It can, but good design is all about reducing this inefficiency.  I 
don't think we can escape modularizing the JIT and the GC---they are 
just too big and too complex.  Prior experience in both production and 
research VMs shows this is possible and in fact desireable.  My feeling 
is that it will be essential for Harmony to leverage pre-existing JITs 
and GCs if it is going to compete.  The investment in these existing 
JITs and GC is enormous.  Of course this does not preclude us building 
our own over time (in fact the modularity precisely enables such an 
approach).

>  Trying to
>guess every need "up front" in a neat module/interface definition is
>doomed to failure.  I believe it is better to start off with a minimal
>interface, and then re-factor as experience dictates.  Of course,
>there are some very experienced VM implementors on this list, and
>several module definitions already, but I like to factor through
>experience not anticipation.
>  
>
I agree with you in principle.  MMTk is a third generation memory 
manager---we tried to factor it as well as we could at each step, but 
only now is it really reaching the level of modularity that we had 
sought (while maintaining performance).   However, I think that the 
core<->GC and core<->JIT interfaces are things that have already been 
successfully factored (with a great deal of thought and effort over many 
years).  I think we need to leverage that experience in our first cut 
Harmony implementation. 

Harmony is not starting from scratch.  It is starting from the 
experience of folks like you and many others on the list with a wealth 
of prior experience.  We will not get things right first time, but I 
think we have so much experience on the table that we should make a 
decent stab at good design at the outset.  Just as you said above, 
investing in good design up-front is essential.

>For the record, I believe JamVM to be fairly well "modularised", each
>distinct component is in a separate file, with a defined interface. 
>There is very little duplicate code, and no private utility
>implementations.  The biggest problem is that as yet, I have no
>abstraction for stack-walking.  Please note, I'm not putting JamVM up
>as an example of a module definition.  I'm sure there are many, many
>problems if you were to look at it in detail towards that end.
>  
>
Sure, but I think we can (and *should*) look at it for inspiration, just 
as we're looking at the other VMs, none of which are perfect in any way 
(which is why Harmony exists! :-)

Cheers,

--Steve


Mime
View raw message