harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: I hope the JVM implements most using Java itself
Date Fri, 13 May 2005 02:44:36 GMT
Davanum Srinivas wrote:

>is there some writeup on the your approach to making JikesRVM "modular
>and composable"?
This is all very much work in progress, but since our thinking on this
task relates so closely to the Harmony goals, I thought it was worth
writing something down.  Two important caveats:

1. I am not making any presumption that this is necessarily the
  direction Jikes RVM wants to go.

2. Please note that this is *not* an official Jikes RVM
  roadmap---most of this has not been openly discussed yet, and
  won't happen until it is discussed first.


o "normalizing" the Jikes RVM code base
 . improved maintainability
 . development with Eclipse
-> reduce impedance to contributions to the project

 Context: Jikes RVM has a number of idiosyncrasies in its code base
          (dependence on a pre-processor, non-standard directory
          structure, weak use of packages...)

o rationalizing the build process
 . improved maintainability
 . use of standard tools
 . support componentization

 Context: Jikes RVM has a baroque build process to support
          configurable builds (architectures, compilers, GC
          algorithms can all be selected).  The process depends on
          configuration files and heafty shell scripts, rather than
          orthodox build processes.

o improved componentization
 . improved maintainability
 . development with Eclipse
 . pluggable GCs, compilers
-> strength through diversity of components
-> encourage non-trivial contributions (a new compiler)

 Context: Jikes RVM has a number of key components, not all of
          which are well factored.


o identify and isolate components
 a) mutually exclusive (object model, arch (IA32/PPC))
 b) runtime selectable (compiler)
 . structure packages so that these components map closely to the
   Eclipse notion of project (self-contained modules of code)

o compile components to standalone jars
 . use stubs to isolate against specifics
   - For example with MMTk (Jikes RVM's memory manager), the
     org.mmtk.vm subpackage implements a bunch of vm-specific stubs
     which are fleshed out by any particular client VM (Jikes RVM
     or jnode, for example).  The mmtk.jar builds against the
     stubs, but does not include them.  When the VM is composed,
     the appropriate org.mmtk.vm implementation is put in place.

o building/composing a system
 . mostly consists of fairly simple scripts that
   - define configuration-specific constants (eg BYTES_IN_WORD)
   - "stitch" together some selection of the above jars


We are just about at the point of completely achieving our goals with
regards to componentizing MMTk.  The final patches are being tested
right now.  Applying the above approach to the rest of the VM should
not present many technical difficulties since the memory manager has
the most complex interface, but will be a *lot* of work given our
current resources.  Of course an injection of new energy could
completely change this.

View raw message