Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <4292EA7F.9070507@earthlink.net>
References: <4292C425.50408@anu.edu.au> <4292EA7F.9070507@earthlink.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <07740212-E6C9-4B0F-8216-1D87371C9758@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: Terminology etc
Date: Tue, 24 May 2005 05:52:16 -0400
To: harmony-dev@incubator.apache.org


On May 24, 2005, at 4:49 AM, Dmitry Serebrennikov wrote:

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

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.

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

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.

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.

I'd sure like to see some of the existing thinking on this from the  
JikesVM peeps....

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.

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.

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 :


interface Discovery {
      Object queryInterface(UUID interfaceID);
}

interface JIT extends Discovery {
     //   JIT API here
}

So in my GC implementation, an init() call that's involved when it's  
being created :

void init(Discovery hubDiscovery) {

     JIT commonJIT = (JIT) hubDiscovery.queryInterface 
(UUID_FOR_STANDARD_JIT_API);

     // now lets see if this JIT knows the secret handshake

    CustomJIT goodJIT = (JIT) commonJIT.queryInterface 
(UUID_FOR_JIT_I_ALSO_WROTE);

    if (goodJIT != null) {
        ....
    }
}


and in my JIT implementation :

Object queryInterface(UUID id) {

  if (UUID_FOR_STANDARD_JIT_API.equals(id)) {
     return this;
  }

  if (UUID_FOR_JIT_I_ALSO_WROTE.equals(id)) {
      return myInternalCustomJIT;

  return null;

}


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>

geir


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

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org