harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafal Lewczuk <rafal.lewc...@gmail.com>
Subject Re: [modules] classloader/jit interface
Date Mon, 27 Jun 2005 05:58:29 GMT

On 6/27/05, Robert Lougher <rob.lougher@gmail.com> wrote:
> 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.

Uh, it is always easier to read, then judge someone else's code than
to design and program it oneself. I didn't think much about
sophiscation mainly because all I see in JamVM code I'm getting 'for
granted' - this is the first VM I've began dealing with. Designing and
coding quite sophiscated interpreter and ensuring it is still compact
and readable is always better than coding a horribly sophiscated beast
that no one actually understands. I was playing a bit with JamVM code
and concluded that it may be a good starting point because it is short
enough and reasonably clean (at least from my point of view). But I'm
definitely not an expert (or even fluent).

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

Getting out some code early is quite important in OSS projects. Mono
folks did it extremal way, initially releasing a buch of non-working
empty stubs which sparked wider work and attracted developers. It has
some downsides too (not to say we should go the same route), but it
actually worked.

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


> > >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.
> 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?).
> Pluggable components might achieve this, but pluggability adds an
> overhead in itself (unless it's compile time).

And now I'm not sure if trying to achieve all these targets in one
design actually makes sense. Things like ORP (and propably Jikes - not
sure) are intentionally omitting interpreter, relying on a fast,
non-optimizing JIT instead. I don't know but it may affect some design
decisions. Assuming that framework = set of interfaces (for example
GC) + set of conventions (for example, stack layout), discarding
interpreter part in a server VM may lead to more opportunities in
optimizing VM. On the other hand, resource constrained environments
require VMs with as little footprint as possible. My question is: does
it make sense to make all-in-one framework or maybe designing two
execution engines, maybe sharing some code but having two different
designs (object layout etc.) ? What are the upsides/downsides for
having one versus two execution engines ?

View raw message