Memory introduction of Java virtual machine, Java Virtual Machine Introduction

Memory introduction of Java virtual machine, Java Virtual Machine Introduction

This article describes the Memory Distribution of the Java Virtual Machine and the creation process of objects.

I. Memory Distribution of Java virtual machines

Before the beginning of this article, you need to know how the data partitions of Java virtual machines are divided. As shown in:

1. Program Counter (Program Counter Register)

The program counter is a small memory space, which can be seen as the row number indicator of the bytecode executed by the current thread.

Java Virtual Machine multithreading is implemented by switching threads in turn and allocating the processor execution time. Therefore, at any specific time, a single processor (for multi-core processors, It is a kernel) only the commands in one thread are executed. Therefore, in order to restore the thread to the correct execution position after switching, each thread needs an independent program counter.

Counters between threads do not affect each other and are stored independently. We call this type of memory region as "thread-private" memory.

Readers familiar with C ++ should understand the concept of "Field Protection". Although "Field Protection" corresponds to function calls, the program counters here correspond to switching between threads, however, I think they play a very similar role: they are used to restore the thread or function to the correct position after execution.

 

2. Java Virtual Machine Stacks)

The stack area we usually call is the Java Virtual Machine stack.

Like program counters, Java Virtual Machine stacks are also proprietary to threads, with the same lifecycle as threads.

The Virtual Machine Stack describes the Memory Model of Java method execution: each method creates a Stack Frame to store the information of this method at the same time, such as the local variable table, the operand stack, and the method exit information.

The process from calling to execution completion of each method corresponds to the process from Stack rollback to stack exit.

The local variable table stores various basic data types (boolean, byte, char, short, int, float, long, and double) and object references (reference type, not the object itself) and returnAddress type (pointing to the location of a bytecode instruction ).

The Java virtual machine specification specifies two exception conditions for this region: StackOverflowError and OutOfMemoryError.

 

3. Java Heap)

Java heap is the largest part of memory managed by the Java Virtual Machine. The memory is shared by all threads and is created when the virtual machine is started. The only purpose of this memory area is to store object instances, where almost all object instances are allocated memory. Since almost all instances are stored in the Java heap, this naturally becomes the main area of the garbage collector management.

When no memory is allocated to the instance and the heap cannot be expanded, an OutOfMemoryError is thrown.

 

4. Method Area)

The method area is the same as the Java heap, and is the memory area shared by each thread.

It is used to store data such as class information, constants, static variables, and Code Compiled by the real-time compiler loaded by virtual machines.

The method area also includes the runtime constant pool.

When the method area cannot meet the memory allocation requirements, an OutOfMemoryError error is thrown.

 

5. Native Method Stack)

The local method stack is very similar to the Virtual Machine stack. The difference is that the virtual machine stack executes the Java method (also known as bytecode) service for the virtual machine, the local method stack is the Native method service used by virtual machines.

In the virtual machine specification squadron, the language used for the local method stack method, the mage used and the data structure are not mandatory, so the specific virtual machine can freely implement it. Even some virtual machines (such as Sun HotSpot virtual machines) directly combine the local method stack with the Virtual Machine stack.

The exception thrown in this data zone is the same as the VM Stack: StackOverflowError and OutOfMemoryError are thrown.

 

6. Runtime Constant Pool)

The runtime constant pool is part of the method area. Although the Java Virtual Machine does not separately divide the memory space for the runtime pool, this area is also an important part of normal development, so it also lists an entry separately.

In addition to the description information of the version, field, method, and interface of the Class, the Class file also contains the Constant Pool Table ), it is used to store various literal references generated during the compilation period. This part of content will be stored in the method zone runtime pool after the class is loaded.

Another important feature of the runtime constant pool relative to the Class file constant pool is that it is dynamic. Java does not require constants to be generated only during compilation, that is to say, it is not the content of the constant pool preset into the Class file that can enter the runtime constant pool in the method area. During the runtime, new constants may also be placed in the pool, such as the intern () method of the String Class.

Since the runtime constant pool is part of the method area, it is naturally restricted by the method Area Memory. When the constant Pool cannot be applied to the memory again, an OutOfMemoryError error is thrown.

 

Ii. Object creation process

Java is an object-oriented language. During Java program running, objects are created all the time. In terms of language, general production is just a new Keyword, but it is not that simple in virtual machines:

When the VM encounters a new command, it first checks whether the parameter of this command can locate a Class symbol reference in the constant pool, the symbolic reference indicates whether the class has been loaded, parsed, and initialized. If no, the corresponding class loading process must be executed first. After the class loading check is passed, the VM allocates memory for the new object in the Java heap (the memory size required by the object can be completely determined after the internal loading is complete ). Next, the VM needs to make necessary settings for the object, such as the instance of the class of the object, the hash code of the object, and the GC age of the object. This information is stored in the Object Header.

After the above work is completed, from the perspective of the Virtual Machine: a new object has been generated, but from the perspective of the Java program: the object has just been created. The <init> method has not been executed, and all fields are still zero. Generally, after the new command is executed, the <init> method is executed to initialize the object as the programmer wishes. Such a truly available object is generated completely.

 

This article is the first article by the author. Errors and deficiencies are inevitable in this article. please correct me.