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 [arch] Modules and interfaces (was: How much of java.* ...)
Date Mon, 06 Jun 2005 21:35:41 GMT
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 

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 

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


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


View raw message