Java bytecode constant pool depth analysis and byte-code integral structure decomposition

Constant Pool Depth Profiling:

In the last "https://www.cnblogs.com/webor2006/p/9416831.html" The constant pool has been analyzed to 2/3, and then the rest of the analysis, the first review of our compiled source files are:

Then use Javap-verbose to view the compiled bytecode information, where the string is related to the following:

The location of the binary file that applies hex fiend to view the character code is as follows:

In addition, before proceeding with the analysis, we will review the corresponding table of constants as follows:

Okay, here we go. read a byte to see what type of constant:

Check the table to see that it belongs to this constant:

Then 2 bytes represents the length of the string, so the number is two bytes down:

Length is 4, then the number of 4 bytes down is the content of the constant:

Use Javap-verbose to confirm if it is also:

Then continue reading one byte:

Is the same constant type, so read the two bytes directly to see how long the string is:

Length is 3, then count back 3 bytes:

Take a look at Javap-verbose:

In fact, "Geta () I" can confirm that its method name is Geta, no parameter, and the return value is integral type, it can be completely corresponding to the method in the source program.

Next go down and read a byte:

The same type, not much, goes straight down and looks at two bytes to determine the length of the string:

Takes four bytes, and then counts four more bytes:

For a moment, Javap-verbose:

Continue down and read one byte:

Count 2 more bytes:

Count down to four bytes:

Corresponds to Javap-verbose:

The same "SetA (I) V", which means that the method name is SetA, the parameter of the method is integral type, no return value, so that you can locate the specific method.

Continue down:

Count down to 10 bytes:

corresponding Javap-verbose:

represent the source file, and then read down:

The length is 12 and the number is 12 bytes down:

These two messages describe which source file the current bytecode file is compiled from, so this is why you have the following message when executing the JAVAP command:

Keep going down:

At this point is no longer a constant of 01 type, but 12, so the specific it represents what type still have to look up the table, as follows:

The second item represents the index of the name, and the third item is the index of the description, so read down to 4 bytes:

Take a look at what Javap-verbose shows:

Where the method name is a <init> representation is a construction method, and () v means that the constructor method does not have a return value with no parameters, it is also the default constructor method.

Then continue:

Is the same constant, so just four bytes back:

corresponding Javap-verbose:

This information represents the member variable A, as follows:

Keep looking down:

string constant, the analysis of it is very familiar, the next number of two bytes to see the length of the string:

The length is 24, then the number of 24 bytes:

corresponding Javap-verbose:

Represents the globally qualified name of the class, noting that the globally qualified names are separated by "/" in the case of a bytecode file, rather than as the package name we see. Separate, continue down:

Then count down to two bytes:

16, the number is 16 bytes down:

corresponding Javap-verbose:

Represents the fully restricted name of the parent class of the current class, where the constant pool is all analyzed ~ So, to summarize, the size of a class constant pool is variable, how does the JVM know where the Chang ends in the font code file? First the character code can know the total size of the constant pool, as follows:

is 24, but because the first is reserved, the size of the total constant pool is 23, and the first byte of each constant is a constant of what type, and then a different constant reads a few bytes down, so you know where to read the constant pool ends.

BYTE-code integral structure decomposition:

The entire constant pool has been analyzed above, and then there are so many bytes:

corresponding Javap-verbose:

classfile/users/xiongwei/documents/workspace/intellijspace/jvm_lectue/out/production/classes/com/jvm/bytecode/ MyTest1.classLast modified10, 2018; Size 479bytes MD5 checksum 4616561f95c24d6b04ea48a360437b8d Compiled from"Mytest1.java" Public classCom.jvm.bytecode.MyTest1 minor version:0Major Version:52flags:acc_public, Acc_superconstant pool: #1 = methodref #4. #20//java/lang/object. " <init> ":() V#2 = Fieldref #3. #21//COM/JVM/BYTECODE/MYTEST1.A:I#3 = Class #22//Com/jvm/bytecode/mytest1#4 = Class #23//Java/lang/object#5 =Utf8 A #6 =Utf8 I #7 = Utf8 <init>   #8 =Utf8 () V #9 =Utf8 Code #10 =Utf8 linenumbertable #11 =Utf8 localvariabletable #Utf8 = This  #= Utf8 lcom/jvm/bytecode/MyTest1; #14 =Utf8 Geta #15 =Utf8 () I #16 =Utf8 SetA #17 =Utf8 (I) V #18 =Utf8 SourceFile #19 =Utf8 Mytest1.java #Nameandtype = #7: #8//"<init>":() V#21 = Nameandtype #5: #6//A:I#22 = Utf8 com/jvm/bytecode/MyTest1 #Utf8 = java/lang/Object{ public Com.jvm.bytecode.MyTest1 (); Descriptor: () V flags:acc_public code:stack=2, Locals=1, args_size=1 0:aload_0 1:invokespec ial #1//Method java/lang/object. "         <init> ":() V 4:aload_0 5:iconst_1 6:putfield #2//Field A:I 9:return linenumbertable:line 3:0 line 4:4 localvariabletable:start Length Slot Na  Me Signature 0 0 this lcom/jvm/bytecode/mytest1;    public int geta ();      Descriptor: () I flags:acc_public code:stack=1, Locals=1, args_size=1 0:aload_0 1:getfield         #2//Field A:I            4:ireturn linenumbertable:line 7:0 localvariabletable:start Length Slot Name Signature  0 5 0 This lcom/jvm/bytecode/mytest1;    public void SetA (int); Descriptor: (I) V flags:acc_public code:stack=2, locals=2, args_size=2 0:aload_0 1:iload_1 2:putfield #2//Field A:I 5:return linenumbertable:line 11:0 line 12:5 localvariabletable:start Length Slot N            Ame Signature 0 6 0 this lcom/jvm/bytecode/mytest1; 0 6 1 A i}sourcefile: "Mytest1.java"

At present there is no analysis, because there is still a lack of knowledge theory, so first to complement the knowledge, first to the overall structure of the bytecode has an understanding, first look at the picture:

We have now learned the first three structures, as follows:

Next, we'll look at the new byte structure, followed by "Access Flags," which represents the access modifier:

such as: public, public static, public abstract, private, protected and so on.

Then the name of the current class is shown below:

And then down to the name of the parent class:

Next, the interface-related information is represented:

One of the details can be found:

The number of bytes of the parent class is deterministic, and the interface is not true, which is also the same as Java's single-Inheritance multi-implementation feature kiss and.

Continuing down is the field-related information:

This is followed by some information about the method of the class:

This is more complicated because there are code execution in the method that will be learned in the future.

Finally, some additional properties of the current class are represented:

Because the JVM adds some specific property information at compile time.

Java bytecode constant pool depth analysis and byte-code integral structure decomposition