...
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 klassOopInstanceKlass, and walk that list seeking the current target interface.
Once that interface is found (within the receiver's klassOopInstanceKlass), 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 klassOopInstanceKlass, an associated offset directs the assembly stub to an itable embedded in the klassOop the InstanceKlass (just after the vtable, as one might expect). At that point, invocation proceeds as with virtual method calls.
In the interpreter, the state of a linked invokeinterface instruction consists of two words (both in the constant pool cache): The interface being sought, and the index within that interface's itable of the method being called. (There is no need to search for symbolic method names as in message-oriented languages; only the interface needs to be searched for.) In some very rare corner cases (as with invokevirtual), the linkage state of an invokeinterface instruction might actually direct the interpreter to treat the call equivalently to an invokestatic invokespecial or invokevirtual. That latter case can occur when an interface declares an Object method like hashCode as an interface method; the JVM does not allocate itable slots for those methods.
...
It is a curious fact that the searching process described above, while currently a linear search over an array embedded in the receiver's klassOopInstanceKlass, could also be implemented, with roughly equivalent performance, as a pointer-chasing search over a linked-list representation of implemented interfaces. Indeed, some languages use pointer chasing for dynamic lookup. The advantage of such a representation is a looser coupling between a class and its methods (or in JVM terms, its itables; an itable may contain either single methods or groups of methods). The looser coupling would allow a class to extend its implemented interfaces in a type-safe and compatible manner, just as a SmallTalk class can add new methods with a modest amount of pointer swapping.
...
| No Format | ||
|---|---|---|
| ||
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:
...
|
...