CODEWITHSUNDEEP
javainheritancejvmpolymorphism
Bober02
Bober02

Reputation: 15351

Java - inheritance implementation

Let's consider the simple interface:

interface Simple{
     void doSth();
}

ANd two classes that implement it:

class A implements Simple{

     void someOtherMethod(){ .... }

     void doSth(){ ... }

     private void doSth(int x){ ... }
}

class B implements Simple{

     void methodA(){ ..}
     // many other methods

     void doSth(){ ... }

     private void doSth(Object o, long y){ ... }
}

Now,I can easily write:

Simple s = new A();
s.doSth();

And the polymorphism nature of Java will do the rest. Does anyone know how e.g. Hotspot, makes sure that the Linker will link to the right method, considering there can be many more defined in the implementing classes, or even their return types can be a subclass of the original? Does Java make sure that the interface methods are always starting at some offset in the vtable, e.g. at 0?

Upvotes: 1

Views: 491

Answers (2)

Revin
Revin

Reputation: 115

interface InterfaceA{void method();}
class ClassA implements InterfaceA{void method(){}}
void methodA(InterfaceA[]o){
    for(int i=0;i<o.length;++i)o[i].method();
}
void methodB(ClassA[]o){
    for(int i=0;i<o.length;++i)o[i].method();
}

so calling methodA is much more slower than calling methodB

Upvotes: -1

meriton
meriton

Reputation: 70574

Before we investgate this, let's simplify the example:

interface Foo {
    void bar();
}

class AFoo implements Foo {
    int i;
    
    @Override
    public void bar() {
        i++;
    }
}

class AnotherFoo implements Foo {
    int i;
    
    @Override
    public void bar() {
        i--;
    }
}

public class Test {
    public static void main(String[] args) {
        Foo foo = new AFoo();
        foo.bar();
    }
}

After compiling, we use

javap.exe -verbose Test.class

to inspect the generated byte code:

  public static void main(java.lang.String[]);
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=2, args_size=1
         0: new           #16                 // class tools/AFoo
         3: dup
         4: invokespecial #18                 // Method tools/AFoo."<init>":()V
         7: astore_1
         8: aload_1
         9: invokeinterface #19,  1           // InterfaceMethod tools/Foo.bar:()V
        14: return

At class load time, the code will be linked, which is specified by the Java Language Specification as follows:

The binary representation of a class or interface references other classes and interfaces and their fields, methods, and constructors symbolically, using the binary names (§13.1) of the other classes and interfaces (§13.1). For fields and methods, these symbolic references include the name of the class or interface type of which the field or method is a member, as well as the name of the field or method itself, together with appropriate type information.

Before a symbolic reference can be used it must undergo resolution, wherein a symbolic reference is checked to be correct and, typically, replaced with a direct reference that can be more efficiently processed if the reference is used repeatedly.

Note that this "direct reference" refers to the declaration of the method. In case there are several implementations, the runtime can not, at this time, know which method will be used. That is, polymorphism is not resolved during what the Java Language Specification calls linking, but when the actual method invocation expression is executed. This is specified by the Java Virtual Machine Specification:

Let C be the class of objectref. The actual method to be invoked is selected by the following lookup procedure:

  • If C contains a declaration for an instance method with the same name and descriptor as the resolved method, then this is the method to be invoked, and the lookup procedure terminates.

  • Otherwise, if C has a superclass, this same lookup procedure is performed recursively using the direct superclass of C; the method to be invoked is the result of the recursive invocation of this lookup procedure.

  • Otherwise, an AbstractMethodError is raised.

It is up to the implementation of the JVM how to actually implement this. For the Oracle Hotspot JVM, the documentation contains a rather detailed explanation:

When an invokeinterface call is linked, the linker resolves the call to an abstract target method, in an interface. This boils down to a target interface and a so-called itable index within that interface.

Target interfaces are never statically guaranteed by the JVM verifier; every invokeinterface receiver is typed as a simple object reference. Therefore (unlike invokevirtual calls), no assumptions can be made about the receiver's vtable layout. Instead, the receiver's class (as represented by its _klass field) must be checked more carefully. Where a virtual call can blindly perform two or three indirections to reach the target method, an interface call must first inspect the receiver's class to determine (a) if that class actually implements the interface, and (b) if so, where that interface's methods are recorded within that particular class.

There is no simple prefixing scheme in which an interface's methods are displayed at fixed offsets within every class that implements that interface. Instead, in the general (non-monomorphic) case, an assembly-coded stub routine must fetch a list of implemented interfaces from the receiver's InstanceKlass, and walk that list seeking the current target interface.

Once that interface is found (within the receiver's InstanceKlass), things get a little easier, because the interface's methods are arranged in an itable, or "interface method table", a display of methods whose slot structure is the same for every class that implements the interface in question. Therefore, once the interface is found within the receiver's InstanceKlass, an associated offset directs the assembly stub to an itable embedded in the InstanceKlass (just after the vtable, as one might expect). At that point, invocation proceeds as with virtual method calls.

Nearly the same optimizations apply to interface calls as to virtual calls. As with virtual calls, most interface calls are monomorphic, and can therefore be rendered as direct calls with a cheap check.

Here is a generic instruction trace of a polymorphic interface call:

callSite:
    set #calledInterface, CHECK
    call #itableStub[itableSlot]
---
itableStub[itableSlot]:
    load (RCVR + #klass), KLASS_TEM
    load (KLASS_TEM + #vtableSize), TEM
    add  (KLASS_TEM + TEM), SCAN_TEM
tryAgain:
        # this part is repeated zero or more times, usually zero
    load (SCAN_TEM + #itableEntry.interface), TEM
    cmp TEM, CHECK
    jump,eq foundInterface
    test TEM
    jump,z noSuchInterface
    inc #sizeof(itableEntry), SCAN_TEM
    jump tryAgain
tryAgain:
    load (SCAN_TEM + #itableEntry.interface), TEM
    cmp TEM, CHECK
    jump,eq foundInterface
foundInterface:
    load (SCAN_TEM + #itableEntry.offset), TEM
    load (KLASS_TEM + TEM + #itableSlot), METHOD
    load (METHOD + #compiledEntry), TEM
    jump TEM
---
compiledEntry:
    ...

In all, that is six memory references and two nonlocal jumps.

Pedantic note: All of the above applies to invoking interface methods. Invoking a abstract method declared in a class uses a different bytecode instruction, and a slightly simpler implementation in the Oracle Hotspot JVM.

Upvotes: 2

Related Questions