Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of kumpera@gmail.com designates
 64.233.170.192 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:references;
        b=K8wheVdEiUtwiMtp+gJ5GXT41KsU7Cas87STV9h9I3bsgZ3I9thy/TEMdw/+RbLCc3BE1vIh4WOgGmuk/XLmf/Pe8e2bUUl0PTi8De54dv+sfvy6cQI+eQRyb61tO0qC+2FfzkmqDo1ZeJVijOWBrnJNUqV6+FdzS130+zkZZiA=
Message-ID: <8cca42d8050524043867fcbf61@mail.gmail.com>
Date: Tue, 24 May 2005 08:38:45 -0300
From: Rodrigo Kumpera <kumpera@gmail.com>
Reply-To: Rodrigo Kumpera <kumpera@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Terminology etc
In-Reply-To: <07740212-E6C9-4B0F-8216-1D87371C9758@apache.org>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4231_26163501.1116934725836"
References: <4292C425.50408@anu.edu.au> <4292EA7F.9070507@earthlink.net>
	 <07740212-E6C9-4B0F-8216-1D87371C9758@apache.org>

------=_Part_4231_26163501.1116934725836
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There isn't much space for plugability of components beyond compile-link=20
time. And I see no reason to have it otherwise.

Rodrigo

On 5/24/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
>=20
>=20
> On May 24, 2005, at 4:49 AM, Dmitry Serebrennikov wrote:
>=20
> >
> > * "OS interface" is perhaps one place where some code can be
> > shared. If C version can benefit from an OS abstraction layer for
> > portability, then it seems like this layer could be shared between
> > the C and the Java implementations.
>=20
> I'm really hoping we can shelve the idea of having a C implementation
> and a Java implementation. I think we should try to mix them into
> one solution.
>=20
> >
> > Steve, if the spokes were in Java but the hub in C, would we then
> > lose all of the aggressive inlining benefits that Java-in-Java
> > solution can provide?
>=20
> I'll preface this and state that I have no idea what I'm talking
> about. That said, this reminds me a little of what was done in the
> Geronimo architecture that makes it differ from component
> architectures that use central mechanisms like JMX to let modules/
> components communicate. With Geronimo, the components are given
> references to their dependencies, rather than having them work
> through the central bus to talk between dependencies. This gives a
> big speedup, as the overhead goes away. (Ok, there are 'smart'
> proxies between the components, but that's a detail we can ignore here.
>=20
> I've guessed (and steve confirmed) that the boundaries between the
> modules in a VM aren't "flat" APIs, but something thicker, with a
> good bit of interdependency. So I'd guess that while a central hub
> would be used to let the modules resolve dependencies (The JIT needs
> to talk to the GC and vice versa), it would be something on the order
> of asking the 'hub' (won't use 'core') for something, and getting an
> object back that could be as sophisticated as needed.
>=20
> I'd sure like to see some of the existing thinking on this from the
> JikesVM peeps....
>=20
> As an aside to my aside, Ben and I were musing over ways to do things
> like this, because we thought that in a multi-language-capable VM,
> you'd probably define some minimum interface APIs so that parts in
> different languages would have framework support for
> intercommunication, but also provide a "discovery" mechanism to so
> that like-minded components could talk in a more private, direct way.
>=20
> For example, suppose we are able to define the boundary between GC
> and JIT in a nice way, we'd want any object claiming to be a JIT to
> support that standard API and be able to provide an to the hub to be
> given to any other module an implementation of that interface. So
> you could do any kind of JIT implementation or experimentation and
> plug it in.
>=20
> However, if I wrote both the JIT and GC, I would want my JIT and GC
> to discover that and give each other a "private" API that took
> advantage of each other's internals. Something like what we used to
> do with COM and "QueryInterface", starting with something basic and
> standard, and grubbing around in it to find something better.
> Loosely speaking :
>=20
>=20
> interface Discovery {
> Object queryInterface(UUID interfaceID);
> }
>=20
> interface JIT extends Discovery {
> // JIT API here
> }
>=20
> So in my GC implementation, an init() call that's involved when it's
> being created :
>=20
> void init(Discovery hubDiscovery) {
>=20
> JIT commonJIT =3D (JIT) hubDiscovery.queryInterface
> (UUID_FOR_STANDARD_JIT_API);
>=20
> // now lets see if this JIT knows the secret handshake
>=20
> CustomJIT goodJIT =3D (JIT) commonJIT.queryInterface
> (UUID_FOR_JIT_I_ALSO_WROTE);
>=20
> if (goodJIT !=3D null) {
> ....
> }
> }
>=20
>=20
> and in my JIT implementation :
>=20
> Object queryInterface(UUID id) {
>=20
> if (UUID_FOR_STANDARD_JIT_API.equals(id)) {
> return this;
> }
>=20
> if (UUID_FOR_JIT_I_ALSO_WROTE.equals(id)) {
> return myInternalCustomJIT;
>=20
> return null;
>=20
> }
>=20
>=20
> Anyway, this reminded me of what Ben and I were talking about a few
> days ago. Note that a) I'm just making this up, b) all the above is
> trying to capture some loose ideas on the subject, and c)
> <disclaimer> is all done pre-coffee in a strange hotel room after
> waking up </disclaimer>
>=20
> geir
>=20
>=20
>=20
>=20
>=20
> >
> >
> > -dmitry
> >
> > Steve Blackburn wrote:
> >
> >
> >> I thought it might be helpful to clarify some terminology and a few
> >> technical issues. Corrections/improvements/clarifications
> >> welcome ;-)
> >>
> >> VM core
> >>
> >> The precise composition of the VM core is open to discussion and
> >> debate. However, I think a safe, broad definition of it is that
> >> part of the VM which brings together the major components such as
> >> JITs, classloaders, scheduler, and GC. It's the hub in the wheel
> >> and is responsible for the main VM bootstrap (bootstrapping the
> >> classloader, starting the scheduler, memory manager, compiler etc).
> >>
> >> VM bootstrap
> >>
> >> The bootstrap of the VM has a number of elements to it, including
> >> gathering command line arguments, and starting the various
> >> components (above).
> >>
> >>
> >> In the context of a Java-in-Java VM, the above is all written in
> >> Java.
> >>
> >>
> >> VM boot image
> >>
> >> The boot image is an image of a VM heap constructed ahead of time
> >> and populated with Java objects including code objects corresponding
> >> to the VM core and other elements of the VM necessary for the VM
> >> bootstrap (all written in Java, compiled ahead of time, packaged
> >> into Java objects and composed into a boot image). The boot image
> >> construction phase requires a working host VM (ideally the VM is
> >> self-hosting).
> >>
> >> VM bootloader
> >>
> >> In the case of Jikes RVM a dozen or so lines of assember and a few
> >> lines of C are required to basically do the job of any boot loader
> >> loader---mmap a boot image and throw the instruction pointer into
> >> it. It will also marshal argv and make it available to the VM core.
> >> This is technically interesting, but actually pretty trivial and has
> >> little to do with the VM core (aside from ensuring the instruction
> >> pointer lands a nice place within the boot image ;-)
> >>
> >> OS interface
> >>
> >> The VM must talk to the OS (for file IO, signal handling, etc).
> >> There is not a whole lot to it, but a Java wrapper around OS
> >> functionality is required if the VM is java-in-java. This wrapper
> >> is pretty trivial and one half of it will (by necessity) be written
> >> in C.
> >>
> >> I hope this brief sketch provides folks with a slightly clearer view
> >> of what a java-in-java VM looks like, and some (tentitive)
> >> terminology
> >> we can use to ensure we're not talking at cross purposes.
> >>
> >> Cheers,
> >>
> >> --Steve
> >>
> >>
> >>
> >
> >
>=20
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>=20
>=20
>

------=_Part_4231_26163501.1116934725836--