Geir Magnusson Jr. wrote:
Doesn't this imply that the GNU Classpath interface should add a
second API that *it* should comply with for symmetry? That way you
don't get dependencies on GNU Classpath internals?
I've been a bystander in this discussion as I know very little about the
class library issues. There were obviously a lot of concerns being
discussed in this thread, but I'd just like to respond briefly to the
above...
It brings to mind some of the portability/modularity issues we've been
wrestling with (at great length) with MMTk and the interdependence
between the memory manager and the VM. Our solution is not earth
shattering, but it evolved out of a very long struggle with issues like
the one Geir is alluding to above.
In the end, our "interface" is not in the form of a simple API, but of
reciprocal packages implemented on the MM and VM sides of the fence.
So we have org.mmtk.vm, which captures all VM-specific dependencies,
leaving the rest of MMTk's packages (the bulk of the code) strictly
VM-neutral.
We have a generic template implementation of the org.mmtk.vm package
which serves to define the interface, and against which a VM-neutral
mmtk.jar is built. Each VM then provides a VM-specific implementation
of this package which binds into that VM's services (such as the way
that VM identifies roots for collection, supports mmap(), defines the
size of an address, or whatever...).
At this stage we only have one example in cvs, but there are two others
in various states of development (jnode, which is actively being
developed & Rotor which is a little out of date right now).
http://cvs.sourceforge.net/viewcvs.py/jikesrvm/MMTk/ext/vm/
(the stub directory defines the package abstractly, the JikesRVM
directory has the Jikes RVM - specific implementation)
We want this to be symmetric, so that the VM has a similar arrangement
whereby it can support various memory managers by having each of them
implement some package. We have not yet cleaned up this aspect of Jikes
RVM, but it is on our short list of planned cleanups. MOre generally,
we want to use this model in a complete componentization of Jikes RVM.
--Steve
