Matthew French wrote:
But I am still thinking that we can make it so that we have a choice of multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python or whatever other language takes the authors fancy. I can see many valid reasons why we would want to do this, but the trick is getting it to work without adding enormous complexity.
What worked well for GNU Classpath, and in my opinion helped the cambrian explosion of free runtimes happen, that we witnessed within GNU Classpath in the last two years, was to use Java for the interfaces, and let the VMs do their own marshalling to whatever language they use internally.
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.
How is Classpath done? Is the bulk of the code implemented in C and wrapped in Java? Or is it Java with a thin C api?
The bulk is written in Java. The largest chunk of C in classpath is fdlibm, I believe, which should be eventually kicked out and replaced by VM interfaces to let the VMs optimize Math.*() operations internally any way they want without having to maintiain their separate copy of java.lang.Math.
cheers, dalibor topic
