Re: FYI: Patch: Make Method.invoke() and JNI_CallAnyMethod use vtables

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:

Bryce> This patch improves Method.invoke() and JNI by having them
Bryce> dispatch via the vtable instead of doing runtime lookups via
Bryce> _Jv_LookupDeclaredMethod.

Nice idea!  I've got one question...

Bryce> +// Determine if METH gets an entry in a VTable.
Bryce> +static inline jboolean _Jv_isVirtualMethod (_Jv_Method *meth)
Bryce> +{
Bryce> +  using namespace java::lang::reflect;
Bryce> +  return (((meth->accflags & (Modifier::STATIC | Modifier::PRIVATE)) == 0)
Bryce> +          && meth->name->data[0] != '<');
Bryce> +}

Suppose the method or class is final.  Might  we not wind up making a
virtual-style call where meth->index == -1?

I think the vtable layout code takes this into account elsewhere, so
that the above function (pre-renaming) doesn't need to.

Bryce> It should also fix potential bugs, eg a virtual 
Bryce> call to a package-private method that hides a similar declaration in 
Bryce> its superclass. No "make check" regressions.

We may not have tests for the important cases :-(.
We should.  And a test for the package-private thing would be useful too...

Bryce> Incidentally, JNI calls seem to be at least 10X 
Bryce> slower than the JRE (for java->native calls, which this patch doesn't 
Bryce> effect). I imagine that speeding JNI up would help SWT and AWT 
Bryce> significantly.

I assume you mean a call from java code to a native method implemented
as JNI.  How did you measure this?  I'd guess that the first such call
to a given method would be very slow, then faster on the second call,
after we look up and cache the pointer.

If we're still slow after that, then that is interesting.  We generate
stubs here that shouldn't be too inefficient.  I wonder what we could
do differently.

Tom