Recent top five:
Let's talk about exceptions ...
How do you handle exceptions? Do you think upfront about the type of exceptions that you want to catch or do you just let
the outside world handle it?
-- Jeroen van Bergen in JW Blogs
Featured White Papers
How the Java virtual machine handles method invocation and return
A look under the hood at the bytecodes used for invoking and returning from methods
This month's Under The Hood focuses on method invocation and return inside the Java virtual machine (JVM). It describes the four ways Java (and native) methods can be invoked, gives a code sample that illustrates the four ways, and covers the relevant bytecodes.Method invocation
The Java programming language provides two basic kinds of methods: instance methods and class (or static) methods. The difference between these two kinds of methods are:Instancemethods require an instance before they can be invoked, whereasclassmethods do not.Instancemethods use dynamic (late) binding, whereasclassmethods use static (early) binding.
When the Java virtual machine invokes a class method, it selects the method to invoke based on the type of the object reference, which is always known at compile-time. On the other hand, when the virtual machine invokes an instance method, it selects the method to invoke based on the actual class of the object, which may only be known at run time.
The JVM uses two different instructions, shown in the following table, to invoke these two different kinds of methods: invokevirtual for instance methods, and invokestatic for class methods.
| Opcode | Operand(s) | Description |
|---|
invokevirtual |
indexbyte1, indexbyte2 |
pop objectref and args, invoke method at constant pool index |
invokestatic |
indexbyte1, indexbyte2 |
pop args, invoke static method at constant pool index |
Dynamic linking
Because Java programs are dynamically linked, references to methods initially are symbolic. All invoke instructions, such asinvokevirtual and invokestatic, refer to a constant pool entry that initially contains a symbolic reference. (See my earlier column, "The Java class file lifestyle," for a description of constant pool.) The symbolic reference is a bundle of information that uniquely identifies a method,
including the class name, method name, and method descriptor. (A method descriptor is the method's return type and the number
and types of its arguments.) The first time the Java virtual machine encounters a particular invoke instruction, the symbolic
reference must be resolved.To resolve a symbolic reference, the JVM locates the method being referred to symbolically and replaces the symbolic reference with a direct reference. A direct reference, such as a pointer or offset, allows the virtual machine to invoke the method more quickly if the reference is ever used again in the future.
For example, upon encountering an invokevirtual instruction, the Java virtual machine forms an index into the constant pool of the current class from the indexbyte1 and indexbyte2 operands that follow the invokevirtual opcode. The constant pool entry contains a symbolic reference to the method to invoke. The process of resolving symbolic
references in the constant pool is how the JVM performs dynamic linking.
Verification
During resolution, the JVM also performs several verification checks. These checks ensure that Java language rules are followed and that the invoke instruction is safe to execute. For example, the virtual machine first makes sure the symbolically referenced method exists. If it exists, the virtual machine checks to make sure the current class can legally access the method. For example, if the method is private, it must be a member of the current class. If any of these checks fail, the Java virtual machine throws an exception.Objectref and args
Once the method has been resolved, the Java virtual machine is ready to invoke it. If the method is an instance method, it must be invoked on an object. For every instance method invocation, the virtual machine expects a reference to the object (objectref) to be on the stack. In addition to objectref, the virtual machine expects the arguments (args) required by the method, if any, to be on the stack. If the method is a class method, only the args are on the stack. Class methods don't require an objectref because they aren't invoked on an object.The objectref and args (or just args, in the case of a class method) must be pushed onto the calling method's operand stack by the bytecode instructions that precede the invoke instruction.
Pushing and popping the stack frame
To invoke a method, the Java virtual machine creates a new stack frame for the method. The stack frame contains space for the method's local variables, its operand stack, and any other information required by a particular virtual machine implementation. The size of the local variables and operand stack are calculated at compile-time and placed into the class file, so the virtual machine knows just how much memory will be needed by the method's stack frame. When the JVM invokes a method, it creates a stack frame of the proper size for that method.Adding a new frame onto the Java stack when a method is invoked is called "pushing" a stack frame; removing a frame when a method returns is called "popping" a stack frame. The Java stack is made up solely of these frames.
Invoking a Java method
If the method is a Java method (not a native method), the Java virtual machine will push a new frame onto the current Java stack.In the case of an instance method, the virtual machine pops the objectref and args from the operand stack of the calling method's
stack frame. The JVM creates a new stack frame and places the objectref on the new stack frame as local variable 0, and all
the args as local variable 1, 2, and so on. The objectref is the implicit this pointer that is passed to any instance method.
For a class method, the virtual machine just pops the args from the operand stack of the calling method's frame and places them onto the new stack frame as local variable 0, 1, 2, and so on.
Once the objectref and args (or just the args, for a class method) have been placed into the local variables of the new frame, the virtual machine makes the new stack frame current and sets the program counter to point to the first instruction in the new method.
The JVM specification does not require a particular implementation for the Java stack. Frames could be allocated individually from a heap, or they could be taken from contiguous memory, or both. If two frames are contiguous, however, the virtual machine can just overlap them such that the top of the operand stack of one frame forms the bottom of the local variables of the next. In this scheme, the virtual machine need not copy objectref and args from one frame to another, because the two frames overlap. The operand stack word containing objectref in the calling method's frame would be the same memory location as local variable 0 of the new frame.
- The book The Java Virtual Machine Specification (http://www.aw.com/cp/lindholm-yellin.html), by Tim Lindholm and Frank Yellin (ISBN 0-201-63452-X), part of The Java Series (http://www.aw.com/cp/javaseries.html), from Addison-Wesley, is the definitive Java virtual machine reference.
- Previous Under The Hood articles:
- The Lean, Mean Virtual Machine -- Gives an introduction to the Java virtual machine.
- The Java Class File Lifestyle -- Gives an overview to the Java class file, the file format into which all Java programs are compiled.
- Java's Garbage-Collected Heap -- Gives an overview of garbage collection in general and the garbage-collected heap of the Java virtual machine in particular.
- Bytecode Basics -- Introduces the bytecodes of the Java virtual machine, and discusses primitive types, conversion operations, and stack operations in particular.
- Floating Point Arithmetic -- Describes the Java virtual machine's floating-point support and the bytecodes that perform floating point operations.
- Logic and Arithmetic -- Describes the Java virtual machine's support for logical and integer arithmetic, and the related bytecodes.
- Objects and Arrays -- Describes how the Java virtual machine deals with objects and arrays, and discusses the relevant bytecodes.
- Exceptions -- Describes how the Java virtual machine deals with exceptions, and discusses the relevant bytecodes.
- Try-Finally -- Describes how the Java virtual machine implements try-finally clauses, and discusses the relevant bytecodes.
- Control Flow -- Describes how the Java virtual machine implements control flow and discusses the relevant bytecodes.
- The Architecture of Aglets-- Describes the inner workings of Aglets, IBM's autonomous Java-based software agent technology.
- The Point of Aglets-- Analyzes the real-world utility of mobile agents such as Aglets, IBM's autonomous Java-based software agent technology.