Java Virtual machine 2:java run-time data area

Preface

　　If someone asks you what the memory area of Java is divided into, many people might say: heap, stack, method area .... I personally understand that Java can relate to the "memory Area" from the developer's point of view in two ways: First, the Java Virtual Runtime data area, and the second, Java memory model. Neither of these can be simply referred to as the "memory area of Java".

Java Virtual Runtime data area

　　The Java Virtual machine divides the memory it manages into several different data regions during the execution of a Java program. This is Zhou Zhiming's exact definition of the data area for the Java Virtual Machine runtime in the deep understanding of Java Virtual Machines-JVM advanced features and best practices. post a picture from Http://images.blogjava.net/blogjava_net/nkjava/jvmstructure.png.

• Thread Private Zone:

1. Program COUNTER REGISTER, Procedure counter

The program counter is a small area that stores the address of the bytecode being executed by the current thread (there are actually two "current", one is the thread that is currently being executed by the CPU, and the other is the bytecode instruction of the method being executed in the currently executing thread) . The bytecode interpreter works by changing the value of the program counter to select the next byte code to execute. Since multithreading in Java is done by thread rotation and by assigning the processor execution time, at any one time a single processor (a kernel for a multicore processor) executes only the instructions that are carried in one thread. Therefore, in order for the thread to switch back to the correct execution location, each thread needs to have its own program counter. If the method that the thread is executing is a Java method, the program counter records the bytecode address in the method that the current thread is executing. If you are performing a Native method, the value of the program counter is empty. This area is the only area in the Java Virtual Machine specification that does not stipulate any OutOfMemory conditions.

2.JAVA Stack,java virtual machine stack

　　　　the Java virtual machine stack has the same life cycle as the thread . The virtual machine stack describes the memory model that the Java method executes. Each method creates a stack frame at execution time (one method corresponds to a stack frame, and the stack frame is the basic unit of the stack) for storing the local variable table, the operand stack, the dynamic link, the method exit and other information. Each method, from the start of the thread execution to the end, corresponds to a stack frame that stacks and stacks into the virtual machine stack. The Local Variables table contains the various basic data types (Byte,short,int,long,float,double,char,boolean), object references (reference types, It stores the address of the object, or the handle to the object, and the ReturnAddress type. In the Java virtual machine specification, this area of the heap prescribes two anomalies: the first, if the thread requests a depth greater than the depth allowed by the virtual machine stack (the depth is understood as the number of stack frames, that is, the number of Java methods), the Stackoverflowerror exception is thrown, and the second, The virtual machine stack dynamically expands (the current virtual machine basically supports dynamic scaling), and if the extension cannot request enough memory, it throws a OutOfMemoryError exception.

3.NATIVE Method Stack, local methods stack

The local method stack is similar to the virtual machine stack. ORACLE's HotSpot virtual machines combine the virtual machine stack and the local method stack when implemented. As with the virtual machine stack, the local method stack throws Stackoverflowerror and OutOfMemoryError exceptions.

• Areas of memory shared between threads

1. Heap (GC heap)

There are descriptions in the Java virtual machine specification: All object instances and arrays are allocated on the heap, but with the development of the JIT(just-in-time) compiler and the gradual maturation of the escape analysis technique , all instances of the object are allocated on the heap less " Absolutely. " Since the use of generational recovery algorithm, so from the perspective of memory recovery , the heap can also be subdivided into: the new generation, the old age. The Cenozoic can be divided into: Eden space, from Survivor space, to Survivor space. An OutOfMemoryError exception is thrown if the instance assignment cannot be completed in the heap and the heap can no longer be extended.

2.Method Area

This area is used to store data such as class information that has been loaded by the virtual machine , constants (Representative constants of static final adornments), static variables, code generated by the instant compiler compilation , and so on. Many developers prefer to call the method area "permanent generation". However, due to the fact that the HotSpot team is using the generational recycling algorithm in the method area, the method area is called "permanent generation" according to the naming methods in the heap, and there is no concept of "permanent generation" for Jrocket and J9. The Java virtual machine specification limits the method area very loosely, and even does not implement garbage collection, in general, this area of memory recycling is not satisfactory, especially the type of unloading , the conditions are very harsh, but because the modern framework relies heavily on JIT technology, This leads to a gradual increase in the occupancy ratio of the method area, so it is important to reclaim the method area. According to the Java virtual machine specification, a OutOfMemoryError exception is thrown when the method area does not meet the memory allocation requirements.

3, RUNTIME CONSTANT pool, running the constant-amount pools

This area is part of the method area, class A message in the   file is a constant pool compile time generated various literal (final int x = 1) and symbol reference (final person p = new person ()) , which will be loaded in the Class (ClassLoader load Class Byte-code file) is stored in the run-time pool of the method area. Java virtual machines have strict rules for the format of each part of the Class file (including Chang, of course), and each byte is used to store which type of data must conform to the requirements of the specification to be recognized, loaded, and executed by the virtual machine, but for running a constant pool, Java Virtual machines do not require any details, and different virtual machine providers can implement this area of memory themselves, as they want. However, in general, . Running a constant pool with respect to the class file constants pool An important feature is dynamic, and the Java language does not require constants to be generated in the constant pool of the class file at compile time, and not only constants in the class file constant pool can enter the running constant pool. The process of executing a method in a thread may result in new constants being deposited into the run-time pool, such as The Intern () method of the String class. The OutOfMemoryError exception is thrown when the run-time-constant pool cannot request memory.

　　

Java Virtual machine 2:java run-time data area