Internal Java Virtual Machine Introduction

I. INTRODUCTION

Java's memory management and garbage collection is the same problem in some way. For Java programmers, with the help of the virtual machine automatic memory management mechanism, it is not necessary to write the paired Delete/free code for each new operation, which is not prone to memory leaks and memory overflow problems, and the virtual machine manages the memory it all looks pretty good. However, It is also because Java programmers give the right to memory control to a Java virtual machine, and if there is a memory leak and overflow problem, if you do not understand how the JVM uses memory, then troubleshooting will be an exceptionally difficult task.

1.1 Run-Time data regions

The Java Virtual machine divides the memory it manages into several different data regions during the execution of a Java program. These zones have their own usefulness and time for creation and destruction, and some regions exist as virtual machine processes start, and some are created and destroyed depending on the start and end of user processes.

The memory that the JVM manages consists of the following parts

A. Program counter

Program Counter Register is a small memory space that can be seen as a signal indicator of the byte code executed by the current thread. In the virtual machine conceptual model, the bytecode interpreter works by changing the value of this counter to select the next byte-code instruction to execute, branch, Basic functions such as looping, jumping, exception handling, and thread recovery need to rely on this counter for implementation.

Since multithreading in the JVM is implemented in a way that threads take turns switching and allocating processor execution time, at any given moment, a processor executes only one thread of instruction. Therefore, in order for the thread to switch back to the correct execution location, each thread needs to have a separate program counter, the counters between the threads do not affect each other, isolated storage, we call this type of memory area is "thread-private" memory.

If the thread is executing a Java method, the counter records the address of the instruction that is executing the virtual machine bytecode, or null if the native method is being executed. This memory area is the only area in the JVM specification that does not specify any outofmemoryerror conditions.

B.java Virtual Machine Stack

Like program counters, the Java Virtual machine stack (Java stacks) is also thread-private. Its life cycle is the same as the thread, and JVMs describes the memory model that the Java method executes: Each method creates a stack frame at execution time (stack frame) (The stack frame is the underlying data structure when the method is run) to store information such as local variable tables, operand stacks, dynamic links, method exits, and so on. Each method from the call until the completion of the process, corresponding to a stack frame in the JVMs into the plank path out of the stack process.

Java memory is often differentiated into heap memory (heap) and stack memory (stack), which is coarser, and the division of Java memory areas is actually far more complex. The popularity of this partitioning method only shows that the memory area most closely related to the object's memory powder distribution is the two blocks most programmers care about. Refers to the "stack" is now speaking of JVMs, or is the JVMs in the local variable table.

The local variable table holds the various basic data types (boolean,byte,char,short,int,float,long,double) that are known at compile time, object references (reference types, which are not equivalent to the object itself, It may be a reference pointer to the start address of the object, or it may point to a handle representing the object or other location relative to the object, and the ReturnAddress type (the address that points to a bytecode directive).

The 64-bit length of long and double data takes up 2 local variable space (slots), and the remaining data types occupy only 1. The memory space required for the local variable table is allocated during compilation and does not change the size of the local variable table while the method is running.

In the JVM specification, there are two exceptions to this area: if the thread requests a stack depth greater than the virtual machine allows, the STACKOVERFLOWERROR exception will be thrown, and if the JVMs can be dynamically extended (most of the current JVMs can be dynamically extended, Only a fixed-length JVMs is allowed in the JVM specification, and a OutOfMemoryError exception is thrown if sufficient memory cannot be requested for expansion.

C. Local method Stack

The role of the local method stack with JVMs is very similar, but the difference between them is that JVMs executes the Java method (that is, bytecode) service for the JVM, Native The local method stack is the native method service that the JVM uses. The language, usage, and data structures used by methods in the local method stack are not mandatory in the JVM specification, so the specific JVM is free to implement it. Even some jvms, such as Sun HotSpot, directly merge the local method stack with the JVMs. As with JVMs, the local method stack area throws Stackoverflowerror and OutOfMemoryError exceptions.

D.java Heap

For most applications, the Java heap (Java heap) is the largest piece of memory managed by the JVM. The Java heap is a piece of memory that is shared by all threads and created at the JVM startup. The only purpose of this memory area is to hold object instances where almost all of the object instances are allocated memory. This is described in the JVM specification: all object instances and arrays are allocated on the heap, However, with the development of JIT compiler and escape analysis technology matures, stack allocation, scalar replacement optimization technology caused some subtle changes, all the objects are allocated to the heap is gradually become less absolute.

The Java heap is the primary area of the garbage collector. From the memory recovery point of view, because the collector basically uses the Generational collection algorithm, so the Java heap can also be subdivided into: the new generation and the old age, in the detailed point of Eden Space, from Survivor space, to survivor space and so on. From the memory allocation point of view, the thread-shared Java heap may divide multiple thread-private allocation buffers (thread Local Allocation buffer,tlab). In any case, regardless of the content of the store, no matter what area, the storage is still an object instance, the purpose of further partitioning is to better reclaim memory, or to allocate memory more quickly.

E. Method areas

The method area, like the Java heap, is a memory area shared by each thread that stores data such as class information, constants, static variables, and code after the instant compiler that have been loaded by the JVM. Although the JVM specification describes the method area as a logical part of the heap, he has an alias called Non-heap, which is intended to be distinguished from the Java heap.

For developers who are accustomed to developing and deploying programs on a hotspot virtual machine, many people prefer to call the method area the "permanent generation" (Permanent Generation), which is not inherently equivalent. Just because the design team of the hotspot virtual machine chooses to extend the GC collection to the method area, or use a permanent generation to implement the method area, so that the hotspot garbage collector can manage this part of the memory just like the Java heap, eliminating the effort to write memory management code specifically for the method area. There is no concept of a permanent generation for other JVMs, such as Bea JRockit, IBM J9. In principle, how to implement a method area that is part of the virtual machine implementation details and is not constrained by the JVM specification, but using a permanent generation to implement the method area, is now not a good idea because it is more prone to memory overflow problems. Now there is also the abandonment of the permanent generation and gradually changed to adopt native Memory to achieve the planning of the method area. In the currently released JDK1.7 hotspot, the string constant pool that was originally placed in the permanent generation has been removed.

F. Running a constant-rate pool

Running a constant pool (runtime Constant Pol) is part of the method area. class file In addition to the version, field, method, interface and other descriptive information, there is a constant pool of information (Constant pool Table)

, which holds various literal and symbolic references generated during the compilation period, which is stored in the run-time pool where the class loads the backward into the method area.

The JVM has strict specifications for each part of the class file (which naturally includes Chang), and each byte is used to store which data must conform to the requirements of the specification to be recognized, loaded, and executed by the JVM, but for running a constant pool, the JVM specification does not require any detail. The JVM implemented by different providers can implement this memory area according to their own requirements. However, in general, in addition to saving the symbolic references described in the class file, the translated direct references are also stored in the run-time-constant pool.

Another important feature of running a constant pool relative to the class file constants pool is dynamic, and the Java language does not require constants to be generated only by the compiler, which is not the content of the constant pool that is pre-placed into the class file to enter the method area to run the const pool, and the new constants may be put into the pool during run time. , the Intern () method in the string class is the most exploited feature of the developer.

Since the run-time-constant pool is part of the method area, it is naturally constrained by the memory of the method area, which throws a OutOfMemoryError exception when the constant pool is no longer able to request memory.

G. Direct Memory

Direct memory is not part of the data area that is executed by the JVM, nor is it defined in the JVM specification, but this memory is also used frequently and may cause outofmemoryerror anomalies to occur. In JDK1.4 new NiO ( New input/output) class, which introduces a channel-based I/O mode that can be used to directly allocate out-of-heap memory using the native function library. It then operates through a reference to the most memory of the Directbytebuffer object stored in the Java heap. This can significantly improve performance in some scenarios because it avoids copying data back and forth in the Java heap and the native heap.

Obviously, the allocation of native direct memory is not limited by the size of the Java heap, but since it is memory, it is bound to be limited by the size of the native total memory (including RAM and swap or paging files) and processor addressing space.

Internal Java Virtual Machine Introduction