Re: VMInterface addition: Make native library names part ofVMInterface

[Mark Wielaard]

Hi,

On Wed, 2003-11-05 at 21:31, Bryce McKinlay wrote:
> On Nov 5, 2003, at 5:56 AM, Jeroen Frijters wrote:
> 
> > I think that is in fact what Mark was suggesting and I think this is
> > definitely a good idea. There are a lot of VMs that don't (want to) use
> > JNI for their "native" methods. Having all native methods in the VM*
> > classes makes this much easier.

I was suggesting that. Sorry for not responding earlier. But having you
and Patrik affirm that it is a good thing is more valuable then when
'the guy without his own VM' says it :)

> I think its a mistake for classpath to try to be everything for 
> everyone, even at the expense of elegance and efficiency. At some 
> point, most implementations are going to have to modify it in some way 
> in order to suit their special/custom needs.

Hopefully we won't do it at the expense of elegance 'and' efficiency,
but I agree that sometimes it won't be possible to achieve both. As our
Hacker Guide puts it (even though it leaves out elegance):

        When you write code for Classpath, write with three things in
        mind, and in the following order: portability, robustness, and
        efficiency.
        
        If efficiency breaks portability or robustness, then don't do it
        the efficient way. If robustness breaks portability, then
        bye-bye robust code. Of course, as a programmer you would
        probably like to find sneaky ways to get around the issue so
        that your code can be all three ...

And I am also sure that there might be better designs then the grouping
of platform dependent methods into their own VMInterface classes for
some VMs. But just marking some methods 'native' to indicate that they
are platform dependent is not it. A more efficient (and probably more
flexible) approach might be to introduce some preprocessor that munges
the java source files. But doing that in a clean way will be tricky.

One of the big plus points of defining all platform dependent methods in
VMInterface classes is that it makes clear when you are about to break
Classpath any VM, so you must explicitly document your change. And such
documenting and clear marking of 'special' VM classes makes it a lot
easier for VMs that don't follow classpath CVS all the time, but just
import a new version when we create a new snapshot release.

What I hoped was that by having the VMInterfaces classes clearly marked
as 'special', by being package local, final, having (mostly) static
methods, and starting the name with VM (*), would make it easy for VMs
and compilers to just inline all call to them. Especially if you treat
the Classpath core classes as 'sealed' and compile them as complete
packages. Maybe this is much harder then I imagined.

What would be very beneficial would be if we took the script that gcj
uses to display the changes between current Classpath CVS and gcc CVS
and apply it to all current VMs that use a modified Classpath.
http://gcc.gnu.org/java/libgcj-classpath-compare.html
It has a way to mark changes as 'local' to the VM implementation which
would be very helpful for all Classpath/VM integrators. And if more VMs
used it then it gives the Classpath developers a better clue about what
kind of things have to be adapted for every VM anyway.

I was pleased to hear at the GNU Classpath workshop that at least
Kissme, IKVM and Jaos use an unmodified GNU Classpath as core library
implementation (and I believe JikesRVM also uses a unmodified
Classpath). So we are not doing that bad. But maybe those VM/Compilers
are not as aggressive about efficiency and elegance as gcj is (which
does produce some very fast code!).

But I still like to hear how we can improve the VM/Compiler/Platform
specific parts of GNU Classpath without making life much harder for the
gcj hackers.

Cheers,

Mark

(*) Maybe VMInterface was wrong and we should actually call these
classes Platform_Interface classes.

signature.asc
Description: This is a digitally signed message part