Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rob.lougher@gmail.com designates
 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=YR51aUJ6uV7vEihntZAcojH/zXAO71mgNxbNaib4tmj9LZoNS+q9OgeFtSy2GsqB/4GvdhCxPYBelLA19PWAuHFJm/fVesjhvNGAkF7PaZm4nQc8agAtGr1xBqm59t0ql66hvuXilVtCFrZR1MBwCbvsFD0R0YexSFHYYL2lQOk=
Message-ID: <d58509a805062619055489c0e5@mail.gmail.com>
Date: Mon, 27 Jun 2005 03:05:32 +0100
From: Robert Lougher <rob.lougher@gmail.com>
Reply-To: Robert Lougher <rob.lougher@gmail.com>
To: harmony-dev@incubator.apache.org, Steve.Blackburn@anu.edu.au
Subject: Re: [modules] classloader/jit interface
In-Reply-To: <42BF1AE2.2060909@anu.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <4dd1f3f005062209552dd0f46f@mail.gmail.com>
	 <95E6A6ED-7E50-4DB5-A8A7-2203425BAF67@apache.org>
	 <4dd1f3f0050624141730b88b65@mail.gmail.com>
	 <F6E0FCEF-CCCE-4418-A115-8F10B482C2C5@apache.org>
	 <1cfd215805062416415b05bc95@mail.gmail.com>
	 <2986803005062602024a60bfd9@mail.gmail.com>
	 <d58509a805062608354ced39f7@mail.gmail.com>
	 <42BF1AE2.2060909@anu.edu.au>

Hi Steve,

First of all, I'd like to say I've found the discussions on this list
very interesting.  I don't want anybody to take my comments the wrong
way.  I'm not annoyed or offended in the slightest by people saying
JamVM is simple or trivial -- I simply wanted to put the record
straight.  Many parts of JamVM _are_ relatively simplistic, but some
parts I like to think are relatively advanced, following my own
interests.  These include the interpreter and the thin-locks
implementation.

Writing a VM from scratch requires a wide breadth of knowledge.  I
totally agree that simplistic implementations do not scale, and
retro-fitting advanced techniques can be as much work as implementing
it from scratch.  But with JamVM I made the choice to implement parts
simplisticly to get a complete VM finished and released.  As I'm sure
every VM implementor has experienced, after release I spent a lot of
time fixing bugs and boundary cases, and I didn't make any major
modifications for quite a few releases.  And then once you have users
you're stuck in the bind that you have a relatively stable release,
which acts as a "dead-hand" on making major modifications.  I've made
major modifications to the interpreter, but only after extensive
testing, and with great trepidation.

If I have a point, is that testing should be made an integral part of
any design decisions.  Getting a VM "out there" early enables users to
test it with a wide-range of applications.    But simplistic solutions
as in JamVM can prove problems in the future, but complex solutions
can delay getting a VM out there, for real user testing.  (For the
record, I actually worked on JamVM for over a year before I made a
first release).

JikesRVM is a very complex research-oriented (and I'm not saying that
in a derogatory way) VM.  I'm only giving my opinions on what it's
like implementing a VM from scratch, as a one man team.  I'm extremely
impressed by JikesRVM.  I wrote JamVM initially as a learning exercise
and (pleasurably) ended up with a user base.  I guess JikesRVM was
initially a research vehicle, but is now intended as a wider VM.  We
fit different ends of the spectrum, but I hope we can both co-exist.

After a big preamble, I've also given comments below...

On 6/26/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
> Hi Rob,
>=20
> We'd obviously be shooting ourselves in the foot if we did not make the
> most of JamVM...
>=20

Thanks.  I'm pleased that people think JamVM is a worth-while object
of study.  I believe its main "claim to fame" is its small size rather
than the complexity of any technique (apart from the interpreter).=20
But I couldn't say in more than general terms how it achieves it,
apart from saying that I spent many years squeezing complex programs
into the ZX Spectrum using Z80 assembler (total of 48K).

> >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.
>=20
> >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.
>=20

Yes, and I think the discussions so far have been very useful.  I
personally would like to see code sooner rather than later.  If not
for the simple reason that engineers are happier reading code rather
than design documents.   Code is unambiguous.

> >  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 =3D=3D 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 pa=
th.
>=20

I really hope so as well.  Maybe it's impossible for one VM to span
the spectrum from embedded platforms to multi-processor SMP machines,
and to scale appropriately (best commercial example is J9?).=20
Pluggable components might achieve this, but pluggability adds an
overhead in itself (unless it's compile time).

> >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?
>=20

I'm personally in favour of studying existing VMs and implementing
from scratch (not that I wouldn't agree to JamVM being used, but there
may be legal issues which I need to take off-line).  I'd be happy to
discuss any design aspects of the interpreter or anything else.

> >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.
>=20

I also agree absolutely.  How do you get the advantage of a one man
team, with a design spanning multiple people?  I don't know, but
commercial teams inevitably end up with too much politics in the way,
which limits flexibility.  I'm not saying open-source will be any
different, but I hope technical issues will eventually win out (we're
all engineers).  This is why it's important not to set module
interfaces in stone too early.

> >  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).
>=20
> >  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.
>=20
> 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.
>=20

I don't think we're talking at cross-purposes at all.  I started off
giving reasons why JamVM was so small.   Full modularisation is
important, as it allows for powerful options such as pluggability of
GC algorithms, even dynamically at runtime based on profile
information.  I haven't looked at MMTk (I should).  Assuming the
core<->GC and core<->JIT interfaces were adopted how soon could coding
begin?   There is no interpreter in JikesRVM.  Could one be easily
accommodated?  I don't want to appear to be partisan, but I think
interpreters are useful in very embedded environments.

> >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! :-)
>=20

I guess the decision has been made to use Classpath?  That means most
of the discussion will revolve around VM design issues?

Thanks,

Rob.

> Cheers,
>=20
> --Steve
>=20
>