First knowledge of the JVM byte code

About the JVM and the byte code on it, there is actually enough information on the net, I will simply make an outline and introduction, the right to record it.

stack-based VMS

Java byte code runs on the JVM, as if the machine instruction is running on a physical machine, and is required to follow the instructions of this machine. So knowing the JVM, byte code, requires a little bit of understanding of the JVM. The JVM is a stack-based (stack-based) virtual machine. A long time ago I wrote a virtual machine like a simple.

Stack-based virtual machines the intermediate results of their operands and instruction operations are all in a virtual stack, with a register (register-based)-based virtual machine whose operands and instruction operations are stored in several registers (i.e., memory units). The x86 machine can be understood as a register-based machine.

Byte code is essentially the same as the x86 assembly code, which is nothing more than a bunch of instructions from a machine, where you can illustrate the difference between the following two types of virtual machines:

# stack-based Push 1       # Press immediate number 1 to stack top push 2       # Press immediate number 2 to stack top add          # popup Stack top 2 number Add, result 3 to stack top # Register-basedmov ax, 1    # write immediately count to Register Axadd Ax, 2    # Take the value in Microsoft Dynamics AX 1 with the immediate number 2 to add, storing the results to ax

There is also a lot of data on the web, such as the Dalvik virtual machine and the Sun JVM, in terms of the architecture and execution of the two types of implementations.

As for someone who says that stack-based VMS are better for porting, I don't understand that, because even a register-based implementation doesn't have to really have to map these registers to registers on the physical machine CPU, using memory to emulate performance on a stack-based approach is not sorta?

Knowing the characteristics of the JVM, the various instructions on the JVM are better understood, and if you want to understand how the JVM runs byte code, you need to understand the various structures inside the JVM, such as symbolic parsing, class loader, memory allocation, and even garbage collection. We'll talk about this later.

Byte-code

*.classThe file is already a compiled byte code file, just like the target file compiled by C/s + +, is already a variety of binary instructions. This can be disassembled with the tools in the JDK javap to see the corresponding byte code.

Test.java public    class Test {public        static void Main (string[] args) {            int a = 0xae;            int b = 0x10;            int C = a + B;            int d = c + 1;            String s;            s = "Hello";        }    }

Compile the file: javac Test.java get Test.class , then javap -c Test get:

Compiled from "Test.java" public class Test {public Test (); code:0: Aload_0 1:invokespecial #1//Method java/lang/object. "    <init> ":() V 4:return public static void Main (java.lang.string[]); code:0: Sipush 174 # Push a short onto the stack 0xae=174 3:istore_1 # s Tore int value into variable 1:a = 0xae 4:bipush # Push a byte onto the stack 0x10=16 6 : istore_2 # Store int value into variable 2:b = 0x10 7:iload_1 # load Valu E from Variable 1 and push onto the stack 8:iload_2 9:iadd # add t                    Wo ints:a + b 10:istore_3 # c = a + b 11:iload_3 12:iconst_1 # 1 13:iadd # C + 1 14:istore 4 # d = C + 1 16         : LDC #2         String Hello 18:astore 5 20:return} 

This time against the JVM command table to see the above code, compared to the x86 assembly is much easier to understand, seconds, refer to Java bytecode instruction listings. Each instruction in the JVM occupies only one byte, and the operand is longer, so a complete instruction (opcode + operand) is also variable. There is an offset in front of each instruction, which is actually offset by byte. I think the instructions for the Lua VM are actually done with a bit .

From the above byte code, you will find something different from the perspective of the x86 assembly:

• Local variables are actually indexed to distinguish: istore_1 write the first local variable, istore_2 write the second local variable, the 4th local variable needs to use the operand to specify:istore 4
• The function call is invokespecial #1 also a similar index, which is called the Object base class constructor
• A constant string is a similar index:ldc #2
• *.classDo you also divide the constant data segment and the code snippet?

We need to know more about *.class the format of the file.

class file format

The class file format is also very detailed on the web, such as this Java class file. The entire class file can be described entirely in the following structure:

Classfile {U4 magic;                                Magic number U2 minor_version;                                Minor version number U2 major_version;                          Major version number U2 constant_pool_count;    Constant pool size cp_info constant_pool[constant_pool_count-1];                                 Constant pool U2 access_flags;                                   The access flags for class and interface hierarchies (obtained by | arithmetic) U2 this_class;                                  Class index (pointing to the class constant in the constant pool) U2 super_class;                             Parent-Class indexes (pointing to class constants in constant pools) U2 interfaces_count;                 Interface index counter U2 interfaces[interfaces_count];                                 Interface index set U2 fields_count;                 Number of fields counter field_info Fields[fields_count];                                Field table collection U2 methods_count;              Method Quantity counter Method_info Methods[methods_count];                             Method table set U2 Attributes_count;     Number of attributes Attribute_info Attributes[attributes_count]; //attribute Table} 

This is obviously not a section of the format, the above mentioned function index, constant string index, are stored in the constant_pool constant pool. A constant pool stores a lot of information, including:

• Various literal constants, such as strings
• class, data member, interface reference

The index of the constant pool starts at 1. For the example above Test.java , you can use it javap -v Test to view the constant pools, for example:

Constant Pool:   #1 = MethodRef          #4. #13         //  java/lang/object. " <init>:() V   #2 = String             #14            //  Hello   #3 = class              #15            //  Test   #4 = Class              #16            //  java/lang/object   #5 = Utf8               <init>   #6 = Utf8               () V   #7 = Utf8               Code   #8 = Utf8               linenumbertable   #9 = Utf8               main  #10 = Utf8               ([ljava/lang/string;) V  #11 = Utf8               SourceFile  #12 = Utf8               test.java  #13 = Nameandtype        #5: #6          //  "<init>":() V  # Utf8               Hello  #15 = Utf8               Test  #16 = Utf8               java/lang/object

Each class will have a constant pool.

Summary

To understand the JVM running byte code, you need to know more about the JVM itself, such as symbolic parsing, memory management, and so on:

• JVM Internals
• Understanding JVM Internals

Original address: http://codemacro.com/2015/03/31/intro-java-bytecode/
Written by Kevin Lynx posted athttp://codemacro.com

First knowledge of the JVM byte code