Davanum Srinivas wrote:
Steve,
is there some writeup on the your approach to making JikesRVM "modular
and composable"?
thanks,
dims
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.
Goals:
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.
Approach:
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
Status:
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.
