I was reminded off-list that Jikes RVM's use of GNU classpath's VM/library interface was more complex than I'd described in my previous note. The Foo/VMFoo works quite nicely for us in many cases, especially when the VMFoo class is a holder for VM-specific static methods (eg, VMRuntime, VMSystem, VMString, VMDouble). Jikes RVM don't use it for truly core classes like java.lang.ref.*, java.lang.Class, java.lang.Thread, or java.lang.Throwable where we want more control over the instance fields of the object and/or don't want to incur an extra indirect to get to VM-specific instance data.
Also, GNU classpath doesn't (can't) provide a working reference implementation for every method of every VMFoo class (or even a few other classes like java.lang.reflect.Method and its ilk), so the distinction between its interface and the kernel approach Graeme and Tim described is more a matter of degree and naming convention as opposed to a sharp difference. GNU classpath has a smaller set of mandatory kernel classes that the VM must provide, and also has a "policy" that native methods get segregated into separate classes (which is good for whacky VM's like Jikes RVM that aren't implemented in C, and isn't supposed to hurt C-based VM's assuming reasonable levels of inlining). --dave
