Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>
>> That could be true. I did not think of that. I am not sure what the
>> difference in calling would be between an abstract method and an
>> interface method, or even a overridden non-final method. I know that
>> making methods final, or the concrete class final, can make a difference.
>
>
> I think the methods on the abstract class can be called like
>
> struct Object {
> class* clazz;
> }
>
> struct clazz {
> void* methodTable[];
> }
>
> pObj->clazz.methodTable[<%methodIndex%>];
>
> but the method on an interface needs to be called as
>
> pObj->clazz.getMethodTable(<%interfaceType%>)[<%methodIndex%>];
>
> So there's additional indirection involved here. (I'm just guessing
> though).
>
Yes, there is another level of indirection.
However, given that an interface will always be backed by something
concrete to call when the hotspot has got at it i would have thought
that the data structures for the underlying class would be optimized to
operate on a linear array just like for the non interface virtual method
table e.g.:
pObj->class.vtable[concereteMethodId]
>> We can measure the performance difference between two different builds
>> to see if it makes a difference.
>
>
> Don't worry. I think your change is a better design.
>
OK.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109