As we all know, the JVM used to be interpreted in the past, but later in the history of the revision also added to the implementation of the compilation. So in general the JVM is comprised of interpretation execution and compilation execution. This part does not belong to the scope of the JVM, has been compiled, most of them are lexical analysis and the like, there will be time to add.
At the same time, we all know that now broadly divided into two instruction set architecture, the first is based on the second type of stack is register-based, simple point, register-based architecture faster, but portability is not strong, but the stack-based instruction set architecture is slow, but very portable, We all know that Java itself is known for its portability, so there is no dispute about the use of the stack's instruction set architecture. (There are exceptions, Dalvik is register-based)
Let's take a look at the JVM's stack interpreter execution process, before we start by speaking byte-code instructions Meaning:
Load and store: load and store instructions you can generally put the local variables in the stack frame into the operand stack, and then put the variables in the operand stack back into the stack frame.
load the local variable into the operand stack: There are mainly iload,liload_<n>,lload, (each instruction is preceded by the data type of its operation iload is int lload is long, next we remove the prefix of the previous unification with x instead of reducing space. )
Save the local variable table xstore_<n>,xstore from the operand stack (note that some follow _<n> this is omitting instructions such as xstore_1,xstore_2, Xstore defaults to Xstore_0, After unification with xstore_<n> substitution)
Load a constant to the operand stack:xipush,xdc,xconst_<n>
Operation instruction: Perform subtraction and other operations
Add: Xadd
Minus: Xsub
Multiply: Xmul
Except: Xdiv
Remainder: Xrem
Take the reverse: Xneg
Displacement: XSHL. Xshr
Bitwise OR INSTRUCTION: XOR
Bitwise AND INSTRUCTION: Xand
Bitwise XOR OR instruction: Xxor
Comparison instruction: Xcmpl
We're probably talking so much about the instructions, and then we're looking at the byte-code moment. First write a method like this:
public static void Main (string[] args) {//TODO auto-generated method Stubint A = 2;int b = 1;int C = a+b; System.out.println (c);}
And then we'll use JAVAP to look at the byte code.
You can see that our operation looks at this from the No. 01 two lines. int a = 2, first place the constant 2 to the top of the stack and then take it out to the 1 position in the constant table. 23 likewise.
And 45 of these two numbers is the local variable table on the 12 of the two positions loaded into the Operation Stack, and then add 6 rows added to the position of the constant table 3.
To show that 0123 and 7 really actually store numbers into a constant table, we make the following modifications to the method:
public static void Main (string[] args) {//TODO auto-generated method Stubint c = 1+2; System.out.println (c);}
The byte code is as follows
It is obvious that the storage behavior of the previous 0123 lines is gone, and we can see the optimization that Javac gave us, and in line No. 0 The 1+2 becomes 3 directly.
[JVM Parsing series] [13] Bytecode instruction section, looking at the JVM stack interpreter execution process from bytecode.