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: local policy)
Message-ID: <4292C425.50408@anu.edu.au>
Date: Tue, 24 May 2005 16:05:25 +1000
From: Steve Blackburn <Steve.Blackburn@anu.edu.au>
Reply-To: Steve.Blackburn@anu.edu.au
Organization: Australian National University
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Terminology etc
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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