Hi,
I'd be interested in hearing more from Steve on how well that works within JikesRVM. From reading some papers on the web, it seems that the MMTk has been ported to other, non-Java runtimes as well, and I guess that this binding-vm-components-via-java-interfaces problem has been efficiently solved by other bright people already outside the pure-java-runtime space.
Actually Robin Garner is the expert, as he wrote his honors thesis on the subject. http://eprints.anu.edu.au/archive/00002397/ (MMTk was previously known as JMTk---we dropped the 'J' to reflect our goals of language neutrality).
The short answer is that it is easy enough to compile up the bulk of MMTk into a library using gcj. However, for fine-grained interactions (not an issue with a compiler, but a real issue with write barriers and allocation sequences), one really does not want to go through a C->Java transition each time. What one really wants is for the barrier and allocation fast paths to be compiled into the user application code. In a Java-in-Java system, this happens naturally and automatically (since both the user app and the barrier are in Java and the compiler can inline the barrier code trivially). Otherwise it is a little harder to make this perform well. Exactly how one would approach it would depend on how the compiler dealt with allocation sequences and barriers.
As to the broader issue of componentization etc, here's a very brief overview. I will try to get a better technical write up available to everyone soon...
The model is that MMTk has a reasonably well defined public interface, which we think of in loose software engineering terms as its "features" and "requirements", where the features are a much larger set than the requirements. Likewise the host VM has features and requirements with regards to memory management. We then build adaptors in each direction, satisfying the MM requirments with that VM's features, and satisfying the VM requirements with that MM's features. That glue code is critical, but actually fairly modest. This is how Jikes RVM and MMTk interact today, adn also how Rotor and (soon) jnode glue into MMTk too. The glue code can be written under whatever license you like. You then just link your VM against MMTk. The key to all of this (and this really is the key!) is that the core of MMTk is strictly VM neutral and has no VM-specific code in it whatsoever. This VM neutral core is clearly separated, with all VM-specific code falling under a separate sub-package (org.mmtk.vm) with well defined dummy classes. This means MMTk is never "ported", rather one just writes a suitable adaptor. The above only works once one has got the abstractions right.
I hope this helps.
--Steve
