Shulou(Shulou.com)05/31 Report--

In this article, the editor introduces in detail "what is the bytecode execution engine in the virtual machine". The content is detailed, the steps are clear, and the details are handled properly. I hope this article "what is the bytecode execution engine in the virtual machine" can help you solve your doubts. Let's follow the editor's ideas to learn new knowledge.

We know that the main task of the Java virtual machine is to load the class file and execute the bytecode in it. The function of loading class is implemented by the classloader, so the function of executing the bytecode is performed by the bytecode execution engine. The following figure shows the basic structure of the virtual machine.

There are many kinds of execution engines for virtual machines, and there are great differences among different execution engines. The main differences are as follows:

The simplest execution engine is to interpret bytecode at once.

Another execution engine is called a compiler, but it consumes a lot of memory. The execution engine will compile the bytecode executed for the first time into the local machine code, and the local machine code will be cached. When the method is called for the second time, the local machine code in the cache can be directly used to improve the efficiency of the program.

There is also an execution engine called adaptive optimizer. When the virtual machine executes bytecode, it monitors the most frequently used code in the program and compiles it into native machine code, while the rest of the bytecode continues to be bytecode. In this way, when the program is frequently called and compiled into local machine code, it will improve the running efficiency of the program, but because all the bytecode is not compiled into local machine code, so the execution engine in this way takes up less memory than even the compiler.

The execution engine is made up of hardware chips that execute bytecode with native code.

All of the above are the execution characteristics of different execution engines, but the most basic function of any execution engine is the execution bytecode. Let's take a look at how to ensure the correct execution of bytecode inside the execution engine.

Stack frame

Stack frame is the data structure of method invocation and method execution by virtual machine. The stack frame stores the local variable table, Operand stack, dynamic connection and method return address of the method. From the beginning of the call to the end of the execution of each method, the process inside the virtual machine is the process of the stack frame in the stack from the stack to the stack. In a virtual machine, the stack operates for threads, that is, each thread has a separate stack memory. If the method call chain in the thread is long, and many methods are executed at the same time. So how does the virtual machine ensure that the method is called normally?

In fact, for the execution engine, in the active thread, only the stack frame at the top of the stack is valid, it is called the current stack frame, and the method associated with this stack frame is called the current method. The bytecode instructions that execute the engine runtime operate on the current stack frame. The following figure is a conceptual map of the stack frame.

Next, we focus on sharing the function and data structure of local variables, Operand stack, dynamic connection, method return address and other parts in the stack frame.

Local variable scale

The local variable table is the memory space for storing variables, which mainly stores the method parameters and the local variables defined within the method. The virtual machine uses the index to access the variables in the local variable table, and the index starts at 0. When the method is executed, the virtual machine uses the local variable table to complete the process of transferring the parameter values to the list of parameter variables. If you are executing an instance method (a non-static method), then the 0th index in the local variable table stores an instance of the object to which the method belongs by default, which is the this keyword we used in our development.

Operand stack

The Operand stack is a LIFO stack. The Operand stack can store any Java data type. When a method is first executed, the Operand stack of the method is empty. In the process of method execution, there are various bytecode instructions to write and extract content to the Operand stack, that is, out-stack and stack-on-stack operations. Let's take a look at how the Operand stack is handled if the addition of two int-type data is performed in Java. First, you need to stack two int-type data, and make sure that the two int-type data must be closest to the top of the stack. When this add instruction is executed, the two int type data are added out of the stack, and then the added result is performed on the stack. The data types in the Operand stack must match the bytecode instructions, like the addition operation in the above instructions, because we are performing the addition operation of the int type, so when executing, the two data types closest to the top of the stack must be of type int, and there can be no addition of a long and a float. The above check operation is performed both when the compiler executes and when the class is loaded.

Under normal circumstances, Operand stack and Operand stack are independent of each other. However, some processing is usually done when the virtual machine is optimized, that is, the two Operand stacks will overlap, that is, this part of the data will be shared when the method is called. The goal is to reduce additional operations such as parameter passing and copying.

Dynamic connection

Each stack frame has a reference to the method to which the stack frame belongs to the runtime pool, and this reference is held to support dynamic connections during method calls. We know that there are a large number of symbolic references in the constant pool of class files, and method calls in bytecode take symbolic references that point to methods in the constant pool as parameters. Some of these symbolic references are converted to direct references during the class loading phase or the first time they are used, which is called static parsing. The other part is converted to a direct reference during each run, which is called a dynamic connection.

Method returns the address

When a method is executed, there are only two ways to get the virtual machine out of the method. They are:

The execution engine encounters a bytecode instruction returned by any method, which is equivalent to the return keyword. This way of exit is called normal completion exit.

Another way to exit is to encounter an exception during method execution. And this exception program is not handled, that is, no matching exception handler is retrieved in the exception table of this method, which will cause the method to exit. The exit in this way is called an abnormal completion exit.

The actual process of exiting the method is to unstack the current stack frame. The specific logic of method exit is to restore the local variable table and Operand stack of a method, press the return value (if any) into the Operand stack of the caller stack frame, adjust the value of the PC counter to point to an instruction after the method call instruction, and so on.

After reading this, the article "what is the bytecode execution engine in the virtual machine" has been introduced. If you want to master the knowledge of this article, you still need to practice and use it before you can understand it. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.