On Tue, 2005-06-07 at 07:35 +1000, Steve Blackburn wrote: > 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.
I will most probably be told why not very shortly, but is it not possible to use the class loader to solve this problem? My first solution would be too implement VM specific functions in their own library, but using existing the namespaces, not creating new ones. So you have your own java.lang.Thread, for example, that works with your VM. The class loader then uses the VM specific functionality to override the generic functionality. This acts like a mask, hiding functionality that the VM authors decide is specific to the VM, but leaving all the other generic functionality exposed. This has the advantage that it reduces the amount of re-work while allowing enormous flexibility. The only requirement is that the class libraries call the public API instead of internal implementation classes - i.e. make no assumptions about the implementation of any other class (as much as possible, anyway). This also makes it possible to inject, for example, a VM specific String class, or specially tuned Socket classes. But at the same time for other VM's to use the generic String class. The principal can be extended so that application specific classes can override the generic classes. Although this is wrong for so many other reasons. :( >From a brief look at the classpath docs, it looks like classpath uses a similar approach - from what I can tell the one I am suggesting is just more generic. Or is the issue deeper than this? - Matthew
