The implementation of bytecode commands in jvm is important, and the implementation of bytecode in jvm is important.

The implementation of bytecode commands in jvm is important, and the implementation of bytecode in jvm is important.

Java is interpreted and executed, including the dynamic link feature, which provides a lot of space for flexible expansion during parsing or running. How to compile and parse the inheritance, encapsulation, and polymorphism features of object-oriented languages in JVM, how to determine the version of a method call through the bytecode command is the main content to be discussed below. The full text shows how to implement it in JVM based on a simple example of polymorphism.

First, we will briefly introduce several concepts. For more information about the bytecode execution model and the bytecode instruction set, see http://blog.csdn.net/lijingyao8206/article/details/46562933.

I. parsing method calls

In the Class file, a method call is a symbolic reference in the constant pool. The direct reference can be determined only during the loading parsing period or runtime.

The following two commands can be directly referenced during the parsing period. The corresponding method called is also called non-virtual method.

1. invokestatic is mainly used to call static methods.

2. invokespecial is mainly used to call private methods, constructors, and parent methods.

The following two methods can be directly referenced at runtime, but in addition to the final method, the final method can also determine the call version of the method during the parsing period.

1. invokevirtual virtual method, not sure which implementation class to call

2. The invokeinterface interface method can be used to determine the object to implement the interface at runtime.

 

Ii. Dynamic Allocation

First, let's review the concept of static and dynamic allocation. In Java, all the dispatch actions that use static types to locate and execute versions are called static dispatch. In fact, Overload is a typical static assignment. during compilation, you can know the actual version of the method call. In contrast, dynamic dispatch requires that the version of the method be determined at runtime, that is, direct reference. A typical application is OverWrite ). When the invokevirtual command is called, resolving the class and method symbol reference in the constant pool to the direct reference process is the rewriting process. The execution version of the method is determined according to the actual type at runtime.

Iii. Explain execution

Java's interpretation and execution mechanism enables the jaavc compilation process to cover the process of generating a linear bytecode instruction stream from the syntax and lexical analysis of program code to the AST (Abstract syntax tree. The explanation execution is within the JVM, And the stack-based instruction set provides portability support for the entire platform. This is also the cause of slow java execution, because it is not similar to compilation and execution, in the process, more inbound and outbound commands are required, and the stack is a block of memory. frequent access to memory reduces performance.

4. OverWrite example

The following is a simple example to illustrate the rewrite of the bytecode execution model in JVM.

Parent class:

package bytecode;/** * Created by yunshen.ljy on 2015/7/27. */public class Wine {    public String drink(int ml) {        return "drink " + ml + "ml wine";    }}

Subclass:

Package bytecode;/*** Created by yunshen. ljy on 2015/7/27. */public class Beer extends Wine {/*** rewrite the parent class method to realize polymorphism */public String drink (int ml) {return "drink" + ml + "ml beer ";}}

Call:

package bytecode;/** * Created by yunshen.ljy on 2015/7/26. */public class MethodInvotionTest {    public String drink(int ml) {        Wine wines = new Beer();        return wines.drink(ml);    }}

We all know that the result returned by a method call is "drink XX ml beer ". However, during the compilation period, the instructions in the bytecode cannot determine the version of the actually called method. The following describes the bytecode structure of the call method.

public java.lang.String drink(int);    descriptor: (I)Ljava/lang/String;    flags: ACC_PUBLIC    Code:      stack=2, locals=3, args_size=2         0: new           #2                  // class bytecode/Beer         3: dup         4: invokespecial #3                  // Method bytecode/Beer."<init>":()V         7: astore_2         8: aload_2         9: iload_1        10: invokevirtual #4                  // Method bytecode/Wine.drink:(I)Ljava/lang/String;        13: areturn      LineNumberTable:        line 10: 0        line 12: 8

The first new command creates an object and calls the reference to the stack command. #4 after the new command is mentioned above. For a reference to the runtime pool, only the javap command is easy to understand. Next, the dup command is followed by the just-put reference (copy the value at the top of the operand stack and place the "copy" to the top of the stack ). The Invokespecial command is the non-virtual method call command previously introduced. In the operand stack, the Beer constructor is called through one of the references to initialize the object and let another identical reference point to the initialized object, then the stack is popped up with the previous reference (this. Astore_2 saves the reference to index 2 in the local variable table. Aload_2 pushes the value at index 2 in the local variable table to the operation stack. Iload_1 pushes the int parameter, that is, the value at Index 1 in the local variable table, to the operand stack. The Invokevirtual command will execute two values in the operand stack and call the method. The #4 after the instruction is only a symbolic reference in the constant pool, to determine the direct reference of the method. The final areturn statement outputs the value of the method execution result from the stack to eliminate the current stack frame. If the upper layer still calls the current method, the stack frame of the called method is set to the current stack frame ).

The following compares the values in the local variable table and the operand stack after each command is executed to enhance the above operations on the outbound and inbound stacks. First, stack = 2, locals = 3, args_size = 2. We first know that the local variable table of the method occupies three slots, and the size of the operand stack is two slots. Because our method is an instance method (non-class method), we first describe the implicit this keyword command to the first position of the local variable table, occupying a slot. (The structure of the constant pool is no longer drawn below. You can analyze it by referring to the calss file)

 

Here is just a simple example and a review of some knowledge. Knowing the concepts of the JVM execution engine and bytecode instructions makes it easier for us to anticipate the results of program execution and to understand the implementation of design patterns in some java language versions. This is just a reference. We recommend that you try more analysis on the instructions for calling other methods.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.