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 rafal.lewczuk@gmail.com
 designates 64.233.184.200 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=IA5PThlL5yP8sc5ZHp+4e2EFgBk9DEPW1lSDdBwo/LJhM0KSH+MVZoJ9cAI8T/kX/uZFhZFCv2o1k9exwvq8OEJd+qMvU0m4ikP87x2LVOQjbsPYcuB/0/bYXKzq4EXP9hfOnD6M9mxD5e+PIWd4wPtax7OUXxlLRmR6YqEYi7o=
Message-ID: <2986803005062602024a60bfd9@mail.gmail.com>
Date: Sun, 26 Jun 2005 11:02:33 +0200
From: Rafal Lewczuk <rafal.lewczuk@gmail.com>
Reply-To: Rafal Lewczuk <rafal.lewczuk@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [modules] classloader/jit interface
In-Reply-To: <1cfd215805062416415b05bc95@mail.gmail.com>
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>

Hi,

Newbie's thoughts below.

On 6/25/05, Ahmed Saad <myanywhere@gmail.com> wrote:
> 2. which current VM implemention would we start refining as a core for
> Harmony? (or we would write it from scratch)

Newbie's random thought: start with some simple-as-hell implementation
(JamVM may be a good candidate) and refactor it into a modular one
(kind of 'stretching' it onto a 'framework' set of interfaces,
extracting GC, execution engine, class loader etc. one by one).

Upsides:
- it should be easy for newcomers to get in;=20
- while designing, there is still a working implementation, hopefully
passing many of Mauve tests;
- having many pieces in place at start;=20
- JVM simplicity causes design work to be actually easier (than  a
bigger one) by causing refactoring less painful; (albeit harder than
designing and implementing from scratch);
Downsides:
- minimal JVM usually is compact and its compactness causes code to be
very interlinked in many places, so module extraction can be sometimes
irritating and a bit painful;
- dealing with legacy code causes some extra work (and bugs resulting
in misunderstanding legacy code, but working thing along with some
good set of tests makes it actuallly easier to squash bugs early);
- assumptions about object/class/thread/stack/isolate structure layout
are almost surely to be changed and may be hardwired in many places in
the legacy code; this is the harder part of refactoring work;
- minimal JVM design may not have some issues in mind (for example,
JIT, class verifier etc.);

Some other general comments (some are truisms, I know):

- it is important to distinct between innovation/research and good
engineering. While designing framework I'd suggest to use proven
solutions rather than great innovations; after all, a
reliable/production VM has to be released; well engineered framework
shall make research easier after all; that is why I'm rather a
C-camper and I'd suggest to make C-based framework capable to interact
with java modules (having read some earlier posts, this is propably
truism); make sure to make it efficient as some operations (write
barriers, for example) are critical when it comes to performance;
- avoid prematurely sacrificing design for the sake of performance;
profile, locate and remove performance problems; personally, I do not
believe the first release will be faster (or even comparable) with
Sun's implementation (although Sun VM isn't the fastest one in the
world); and make sure that we won't wait forever to get in par with
Sun VM without releasing anything;
- Java-C/C-Java (internal) interface doesn't necessarily have to be
slow; look at GCJ and GCJX ( http://sourceforge.net/projects/gcjx )
and JC (although JC manually loads compiled object and thus does not
use system linker features, like effective code sharing between VM
processes); I think it is possible to generate C-callable shared
libraries from Java code (along with some extra segments for class
metadata etc.); Unix ELF and Windows PE formats are pretty extensible
and we may use a plenty of techniques here (autogenerating dedicated
low-overhead stubs for C, having class metadata embedded in the
library etc.); a plenty of compiling/linking/symbol tricks and
techniques are available here;
- there are many project we can borrow framework ideas from: ORP for
example has some good points about GC and JIT interface; Kaffe uses
COM-like interfaces (GC) etc.
- 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 ?
- 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;
- 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;

Regards,=20
rle