JVM structure BASICS (1)

JVM structure Basics

Some time ago, due to the performance problems of the widely-spread String and StringBuffer, I did a few small experiments and came to some conclusions. However, according to the reaction of netizens, the research did not play a proper purpose, moreover, some netizens also put forward their own opinions and pointed out some of the content in the experiment. In response to their reactions, I decompiled the code for comparison, however, several netizens are still not very convinced, and the results of the previous experiment are not exactly consistent with those obtained by decompilation, because the comparison of decompilation code is basically based on the number of statements, therefore, this comparison cannot be convincing, but it guides me in the next step: Studying JVM commands and JVM structures, only by fully understanding the decompiled code can we draw convincing conclusions.

This article and some articles to be written in the future are some of my experiences in studying JVM specifications. I hope to carry out our next round of in-depth research on the basis of our common understanding.

Well, let's talk less. Let's start with our text.

The JVM execution object is a class file that everyone is very familiar with. It is also called a class file. The compiled code file defined by the JVM specification (although not mandatory, it is an actual file) the format is very detailed, but here we only talk about some macro content. In the future, we will have the opportunity to study the details. The format of the class file required by JVM is a binary format unrelated to the hardware and operating system. It precisely defines the representation of classes or interfaces, and even contains details such as the byte sequence, the byte sequence is usually fixed in the target file format on a specific platform and will not be described.

The data types supported by JVM are almost the same as those defined in the Java language specification. Please note that they are almost the same! That is, the original type and reference type. They can be stored in the variable table, passed as parameters, and returned by methods. More often, they are the objects of operations. Why is it not exactly the same as what is defined in the Java language specification? In JVM, there is a primitive type not available in Java language: returnAddress type ). This type is required by the jsr, ret, and jsr_w commands. Its value is the pointer of the JVM command operation code, and its value cannot be modified by running programs.

In addition, we need to mention the Boolean value. Although it is completely independent in Java, it only provides limited support for it in JVM, as shown in:
There are no separate Boolean commands. The Boolean operations in the source code are compiled as int values.
The JVM directly supports Boolean arrays. The newarray command can create Boolean arrays, while its access and modification operations are performed using the byte array operation commands: baload and bastore. (In JDK1.0, 1.2, and, the Boolean array is encoded as a byte array, with each element being 8 bits)
JVM uses 1 to represent true, and 0 to represent false. The Compiler maps the Boolean Type in the source code to the int type in JVM and must comply with JVM requirements.

In addition, the JVM specification provides a large description of floating-point data. I have no idea about it. It mainly discusses the relationship between JVM floating-point data and IEEE 754.

Another thing to mention about the type is the type check. JVM expects that almost all type checks have been completed before running (usually checked by the compiler), instead of JVM itself. The values of the original type do not need to be marked or checked at runtime to determine their type. They also do not need to be distinguished from the values of the reference type, the distinction work is completed by the JVM instruction set. The JVM instruction set uses different instructions to differentiate the type of values to be operated, such as iadd, ladd, fadd and dadd are all JVM commands used to add two numbers and generate numerical results. However, each command is for a specific type, corresponding to int, long, float, and double respectively.

JVM includes explicit support for objects. A class is a dynamically allocated class instance or an array. The reference type in JVM is a reference to an object. The value of the reference type can be considered as a pointer to an object, an object may have multiple references to it at the same time. objects are always operated, transmitted, or tested by reference.

For reference types, we need to mention null. It initially has no runtime type, but it can be converted to any type, and for null, JVM does not require any specific values to match.

After talking about the above, we will start to get started with what I want to know most when learning JVM. You can get started.
JVM defines several Data areas for running a program, including pc registers, JVM stacks, stacks, and Method areas) runtime Constant Pool and Native Method Stacks. These data zones can be divided into two types based on their lifetime, one is the same as the JVM's lifetime (including the heap and method zone), and the other is the same as the thread's lifetime (other ), the data zone with the same JVM lifetime is created at JVM startup and destroyed at JVM exit, while the data zone with the same thread lifetime is one for each thread, they are created when the thread is created and destroyed when the thread is destroyed.

Since JVM supports running multiple threads at the same time, each thread must have its own PC (program counter) Register, each JVM thread can only execute one method at a time. This method is the current method of the thread. If this method is not a local method, the PC register stores the address of the Current Instruction (JVM instruction). If the current method is a local method, the value of the PC register is not defined. The size of the jvm pc register is large enough to accommodate a local pointer of the returnAddress type or specific platform.

Each JVM thread also has a private JVM stack, which stores frames (as described in the next article ). The JVM stack is similar to the stack in a traditional programming language like C. It stores local variables and partial results, and also assumes some responsibilities in method calls and responses. In addition to the frame push and pop-up operations, the JVM stack cannot be operated directly, so frames may be allocated on the stack. If the JVM stack required for calculation in a thread is larger than the allowed size, JVM will throw the StackOverflowError. If the JVM stack can be dynamically scaled, however, if there is not enough memory available or there is not enough memory to create a JVM stack for a new thread, the JVM will throw an OutOfMemoryError.

The JVM has only one heap shared by all threads. All class instances and arrays are created in the heap. Objects stored in the heap are recycled by an Automatic Storage Management System (also known as garbage collector (gc )). Objects cannot be explicitly released. The JVM assumes that there is no specific type of Automatic Storage Management System, and the storage management technology can be selected based on the system requirements of the implementer. If the size of the memory heap required for calculation is greater than that available by the Automatic Storage Management System, the JVM will throw an OutOfMemoryError.

The JVM has only one method area shared by all threads. The method area is similar to the compiled code storage area of a traditional language or the "text" section of a UNIX process. It stores class structures, such as the runtime pool, code for member and method data and methods and constructor methods (including specific methods used for class and instance initialization and interface type initialization (these specific methods will be discussed later )). Although the method area is a part of the heap logically, the simple implementation of JVM can choose not to collect garbage or compress the method area (in my opinion, the class cannot be detached ). The JVM specification of the latest version (version 2) does not require the location of the method area or the policy for managing compiled code. If the memory in the method area cannot meet a allocation request, the JVM will throw an OutOfMemoryError.

The runtime constant pool is the runtime representation of the constant pool table in the class file. It contains several constants, the range is a method and member reference that must be parsed from the known numeric constants at compilation to the runtime. The runtime Constant Volume pool functions similar to the symbol table in traditional programming languages, but it contains more data than a typical symbol table.
Each runtime constant pool is allocated from the JVM method area. The runtime constant pool for a specific method or interface is created when the JVM creates a class or interface.
When you create a class or interface, If you create a runtime pool that requires more memory than the available content in the method area, the JVM will throw an OutOfMemoryError.
More information about creating a constant pool may be explained in detail later.

The implementation of JVM may use the traditional stack (more generally, the C stack) to support native methods (not Methods written in JAVA ), the local method stack can also be used to implement a parser for the JVM instruction set in a language such as C language. For JVM implementations that cannot load local methods and do not rely on the traditional stack, it does not provide the native method stack. If it is provided, the native method stack is usually allocated to each thread when the thread is created (in my understanding, it should be the thread that needs to use the native method ). If the memory required for thread computing is larger than that allowed by the local method stack, JVM will throw the StackOverflowError. If the local method stack can be dynamically scaled, JVM throws an OutOfMemoryError when there is not enough memory or sufficient content to create a native method stack.

For the above data areas, the JVM specification allows their sizes to be fixed or dynamically scalable Based on computing needs. If they are fixed sizes, the dimension can be selected at creation. The implementation of JVM allows programmers or users to control the initial size of the JVM stack. Similarly, the maximum size and minimum size can be controlled under Dynamic Scaling, and the memory space they use can be non-consecutive.