Re: VMInterface addition: Make native library names part ofVMInterface

[Andrew Haley]

Patrik Reali writes:
 > Jeroen wrote:
 > > Bryce McKinlay wrote:

 > > > Sorry, I think I misunderstood your message. I thought you were
 > > > suggesting moving all the native methods (eg for IO classes) to
 > > > separate VM* classes.
 > >
 > > 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 agree with this. Moving all the native methods in the VM* classes
 > would be easier for the VM implementors, because it is easier to
 > document or find out which methods must be provided (a grep native
 > *.java doesn't help much!).

Well, it depends.  A downside is that this will cause divergewnce
between libgcj and classpath, because of course we won't add another
indirection where it isn't necessary.  We don't have global inlining
in gcj at the moment, and two trips through the PLT for simple native
method invocations would be intolerable.  I suppose we could put some
sort of evil hack into the compiler to redirect such calls to the real
implementation, but I don't like that idea much.

Yea, we will eventually have global inlining so we can redirect
trivial calls.  However, in the presence of inheritance it's not
always easy to do this: binary compatibility says that even a call to
a final method can't necessarily be inlined because the target method
might be made non-final.

Andrew.