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: local policy)
Message-ID: <4425B5CC.9000608@sablevm.org>
Date: Sat, 25 Mar 2006 16:27:40 -0500
From: Etienne Gagnon <egagnon@sablevm.org>
User-Agent: Debian Thunderbird 1.0.2 (X11/20051010)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: SableVM / Harmony Collaboration
References: <8AEB79DC01BE994D8DE3FD02FA5B475B02313645@orsmsx409>
 <4424A83F.5030508@sablevm.org> <4425A5F5.2050503@dellroad.org>
 <4425A9BF.4000500@sablevm.org> <4425ADB7.2080906@dellroad.org>
In-Reply-To: <4425ADB7.2080906@dellroad.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig8E343A2A82544097B3C42BFC"

--------------enig8E343A2A82544097B3C42BFC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Archie Cobbs wrote:
> That makes sense.. i.e., if you want to make it into something of a
> research project to define the best possible Java/VM API then I'd be
> interested in that as well. Of course this will take more work.

I think not.  Internally, SableVM has a pretty modular stucture.  All
we've traditionally done was to add some hook code for Classpath, not
the other way around.  In other words, SableVM has never been designed
around Classpath's VMI (which actually was a moving target when I
started developing SableVM).  So, since we can't use Classpath's code,
then I don't see how it would really help to closely stick to a
Classpath design.  Maybe I will end up with an identical design, yet, my
feeling is that many little things might be different in the new solution.

> First
> of course is defining what the goals and priorities are (if your goal
> were to do it quickly, then re-using the existing Classpath API would
> be the best option imho).

It has always been the philosophy of SableVM project to take the time to
design and implement things as best as we could, instead of taking the
fastest shortcut.  I know, many are anxious to see everything working
together "yesterday".  If anoyone wants to do that, please feel free to
contribute the code that does it.  Personally, I would much like to see
a well defined and correctly implemented VMI, that correctly takes care
of tricky class loading cases, etc.

> - Class loading. Can maintenance of initialized and/or derived types
>   trees be done in Java? Loading constraints? Etc.

Mostly in Java, of course.

> - VM private data structures: could more of these be stored in
>   byte[] arrays, so that Java code can just pass the byte[] array
>   to native code where appropriate?

Pointers must be passed around Java/VM in architecture independent way.
 Byte arrays are one solution for this.

> - Class initialization: SableVM already does this in Java I think.

Of course, it does.

> - Threads

This one's tricky. :-)

> - Exceptions

SableVM has a mix of Java and VM code here.

> - GC: any Java possibilities here?

A C compiler does a very good job at optimizing the garbage collector.
Why write this in slower Java code?  I have trouble seeing even an
adaptive system offering any significant improvement for such code.
Maybe I'm wrong.  I'll let the JikesRVM people school me here.  [Hmmm...
 Dunno if HotSpot server does it in C or Java...  Is there any research
paper that tells us about this?]

> - Bytecode verification

In Java, of course!

Yet, I invite you to read my Ph.D. thesis for tricks on calculating GC
maps without performing full verification.  [Necessary to do in C,
because of bootstrap].

> The more you "push down" the more it starts to get into the "VM written
> in Java" concept a la Jikes RVM.

I have no religious beliefs in either direction.  I say: do it where it
makes the most sense.  Note how JikesRVM is much less "portable" than
SableVM, even if it's written in Java.  Yet, see how faster it is, even
if it's written in Java.

(DREAM WARNING) Personally, I wouldn't mind seeing a hybrid
SableVM/JikesRVM where bootstrap happens in C (no complex platform
dependent image generation process), but adaptive compilation happens in
Java...

> Another idea: the VM API is just POSIX (or some subset), and you have
> some way to manipulate (pack/unpack) C types via Java.

Why would we do in Java what is best done in C?  System calls are better
done in C.  C data structures are better stored in malloc()'d memory
rather than in a moving heap...  (I know; there's a lot of subjectivity
on what is "best").

Etienne

-- 
Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

--------------enig8E343A2A82544097B3C42BFC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEJbXMjyrJi4rH84gRAhSbAJkBGCdVg739cIWNd60xmkuSNwv5agCcCNlT
Yn1pX3igs9BQtiV9eBrFXOo=
=WYRy
-----END PGP SIGNATURE-----

--------------enig8E343A2A82544097B3C42BFC--