Steve, this "clarification of terminology" helped me a lot to understand your approach better. As Java-in-C camper I can even see now the advantages in the approach. But just let me add my 2 cents of pretty wild ideas.
Having read your MMTk papers, it appears to me that the required JAVA extensions look a little bit like parts of P/Invoke* of Microsoft's Common Language Runtime. (P/Invoke is a convenient way to call C functions in the VM without the need to program glue code in C. It must allow memory access over pointers via a Marshal class. Security fanatics should recognize, that such a class can be implemented for Java using JNI.) A comparable mechanism in Harmony would not only be useful for the Java garbage collector but also the OS interface. Maybe it would be possible to extend the boot image approach to some kind of cached images of Java classes and packages, This would require some ELF-like format for compiled Java code. Such a feature might reduce the startup times of applications like Eclipse a lot. If I'm not misinformed the gcj developers want to build something like this. IMHO a self-hosting VM has the advantage, that performance is under your own control. Code in C will always depend on the optimizations provided by the C compiler being used. Additionally all the debugging/profiling/management code can be written in Java and can use the large Java class library. The class library itself provides also the platform abstractions, which will be needed to support Windows and POSIX platforms with the same code. But it might still be that C-implemented modules (particularly the GC) are faster than their Java-implemented counterparts, because they ignore array-index-checking, don't need write barriers and interface calls, etc... One could follow the strategy, that modules must support Java interfaces but might be implemented in C. This strategy would bring us back to an design that doesn't mandate which language has to be used to implement a certain module. Uli
