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
