26.

prev next contents
invokeinterface

invoke an interface method

Jasmin Syntax
     invokeinterface <method-spec> <n> 
<method-spec> is a method specification and <n> is an integer in the range 0-255.

The <method-spec> is a single token made up of three parts: an interfacename, a methodname and a descriptor. e.g.

      java/util/Enumeration/hasMoreElements()Z 
is the method called "hasMoreElements" in the interface called "java.util.Enumeration", and it has the descriptor "()Z" (i.e. it takes no arguments and returns a boolean result). In Jasmin, the characters up to the '(' character in <method-spec> form the interfacename and methodname (the interfacename is all the characters up to the last '/' character, and the methodname is all the characters between the last '/' and the '(' character). The characters from '(' to the end of the string are the descriptor. This is illustrated in the following diagram:
      foo/baz/MyInterface/myMethod(Ljava/lang/String;)V      -------------------         ---------------------              |           --------         |      interfacename          |             |                        methodname     descriptor {{JM - can we have a nicer diagram?}} 
Stack

Before

After
argN
[result]
---
...
arg2

arg1

objectref

...

Description

invokeinterface is used to invoke a method declared within a Java interface. For example, if you have the Java code:

 void test(Enumeration enum) {     boolean x = enum.hasMoreElements();     ... } 
invokeinterface will be used to call the hasMoreElements() method, since Enumeration is a Java interface, and hasMoreElements() is a method declared in that interface. In this example, the Java compiler generates code like:
     aload_1            ; push local variable 1 (i.e. the enum object) onto the stack     ; call hasMoreElements()     invokeinterface java/util/Enumeration/hasMoreElements()Z 1       istore_2           ; store the boolean result in local variable 2 (i.e. x) 
Which particular implementation of hasMoreElements() is used will depend on the type of object held in local variable 1 at runtime.

Before performing the method invokation, the interface and the method identified by <method-spec> are resolved. See Chapter 9 for a description of how methods are resolved.

To invoke an interface method, the interpreter first pops <n> items off the operand stack, where <n> is an 8-bit unsigned integer parameter taken from the bytecode. The first of these items is objectref, a reference to the object whose method is being called. The rest of the items are the arguments for the method.

Then the class of the object referred to by objectref is retrieved. This class must implement the interface named in <method-spec>. The method table for this class is searched, and the method with the given methodname and descriptor is located.

Once the method has been located, invokeinterface calls the method. First, if the method is marked as synchronized, the monitor associated with objectref is entered. Next, a new stack frame is established on the callstack. Then the arguments for the method are placed in the local variable slots of the new stack frame structure. arg1 is stored in local variable 1, arg2 is stored in local variable 2 and so on. objectref is stored in local variable 0, the local variable used by the special Java variable this. Execution continues at the first instruction in the bytecode of the new method.

Methods marked as native are handled slightly differently. For native methods, the runtime system locates the platform-specific code for the method, loading it and linking it into the JVM if necessary. Then the native method code is executed with the arguments that were popped from the operand stack. The exact mechanism used to invoke native methods is implementation-specific.

When the method called by invokeinterface returns, any single (or double) word return result is placed on the operand stack of the current method. If the invoked method was marked as synchronized, the monitor associated with objectref is exited. Then execution continues at the instruction that follows invokeinterface in the bytecode.

Exceptions

NullPointerException - objectref is null

StackOverflowError - no more space in callstack for a new stack frame

Bytecode

In bytecode, after the invokeinterface opcode is a 16-bit unsigned integer index. This is the index of an entry in the constant pool. The entry is tagged as a CONSTANT_InterfaceMethodref entry. This entry has two fields. One field points to a CONSTANT_Class entry in the constant pool whose name is the interfacename from <method-spec>, and the other points to a CONSTANT_NameAndType entry in the constant pool whose name is the methodname from <method-spec> and whose descriptor is the type descriptor from <method-spec>.

invokeinterface takes an additional unsigned byte parameters in bytecode: <n>. <n> is the number of argument words the method takes plus one, (i.e. the second parameter given to the invokeinterface instruction in Jasmin). <n> must match the number of argument words given in the descriptor for the method.

After <n>, there follows a single byte, which must be zero (this byte location is in fact used at runtime by Sun's Java interpreter - it caches a hashing value in this byte, to speed up invokeinterface method lookup).

Type

Description
u1
invokeinterface opcode = 0xB9 (185)
u2
index
u1
<n>
u1
0
See Also

invokevirtual, invokespecial, invokestatic

Notes

1. Of the instructions used to invoke instance methods, invokeinterface is the most complex to implement, and typically the least efficient. See Chapter 10 (Implementation) for more details on this.

2. invokevirtual cannot be used to invoke the special methods <init> or <clinit> - see invokespecial.

3. The <n> and 0 byte parameters in bytecode are present mostly for historical reasons.


prev next contents
Java Virtual Machine, by Jon Meyer and Troy Downing, O'Reilly Associates


Java Virtual Machine
Java Virtual Machine (Java Series)
ISBN: 1565921941
EAN: 2147483647
Year: 1996
Pages: 171

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net