Re: VMInterface addition: Make native library names part ofVMInterface

[David P Grove]

> I am also strongly in favor of putting all VM-specific
native methods in
> VM* classes, and all library-specific native methods outside of VM*
classes.

I suspect the notion of a VM-specific native method
vs. a library-specific native method is pretty fuzzy.  One example
is VMFloat, most VM's would probably view those as library specific, but
Jikes RVM wants to think of them as VM-specific because we can do a better
job of implementing them in a VM-specific way than the native method does
(and we don't want to have to provide our own complete implementation of
Float.java just to change a couple methods).  But, the native method
is VM neutral and works just fine on Jikes RVM, it is just much less efficient
for us.

There are also obviously Java methods that are (or
can be) VM specific. Some of these have been moved to VM* classes, others
have not. I don't think there is an easy solution to this as it is unlikely
that a single VMInterface will fit the needs of all VMs perfectly.  In
some cases (java.lang.ref.* for example), I don't think that it is reasonable
for classpath to try to provide an implementation that will actually work
unchanged on all VMs.  The details of this class are pretty closely
tied into the details of the GC system and there is very little code that
isn't VM specific.

--dave