The memory allocation and operation mechanism of Java learning-----JVM

VM Run-time data region :

The JVM includes the following runtime zones, as defined in the Java Virtual Machine Specification (second edition):

Let's consider a few questions:

How does the 1.jVM work?

How is the 2.JVM runtime memory allocated?

3. In what area do we write Java code (classes, objects, methods, constants, variables, etc.) in the end?

VM Run-time data region:

1. Procedure counter (program Counter Register):

is a small amount of memory space that can be used as the line number indicator of the bytecode that is being executed by the current thread. In the virtual machine concept model (only the conceptual model, the various virtual machines may be implemented in some more efficient way), the bytecode interpreter works by changing the value of this counter to select the next need to execute the bytecode instruction, branch, loop, jump, exception processing, thread recovery and other basic functions need to rely on this Counter to complete.

Because the multithreading of a Java Virtual machine is implemented in a way that threads rotate and allocate processor execution time, at any given moment, a processor (a kernel for a multicore processor) executes only the instructions in one thread. Therefore, in order to recover the thread after switching 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, this counter records the address of the executing virtual machine bytecode instruction, or null (Undefined) If the Natvie method is being executed. This memory area is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerror conditions.

2.java VM Stack (Java virtual machine Stacks):

It is stored in a local variable table (which holds the various scalar types that are known at compile time: boolean,byte,char,short,int,float,long,double), the object's reference (not the object itself, just the reference pointer), the method return address, and so on.

Two exceptions are specified in the virtual stack:

1. If the depth of the thread request is greater than the depth allowed by the virtual machine, the Stackoverflowerror exception is thrown, which is the stack overflow exception. It is easy to throw this exception in the case of recursive invocation methods.
2. If the VM stack can be dynamically extended, when the extension cannot request enough memory space, throw OutOfMemoryError exception, memory overflow.

3. Local methods Stack (native method stacks)

This area has relatively little responsibility for running memory in the JVM. Just execute the native method. Stackoverflowerror and OutOfMemoryError exceptions are thrown if there is insufficient memory in this area.

4.java Heap

This area is the largest chunk of the JVM, and the Java heap is shared by all threads and is the GC's primary recycle zone, which is created when the JVM is started. The only purpose of the Java heap is to hold object instances (all new objects) where instances of most objects are allocated in this area.

It can be seen that the heap can also be divided into Cenozoic (young Generation) and older generation (old Generation). Here's a look at this picture:

• Cenozoic: The GC will be recycled at intervals, and when the allocated object encounters insufficient memory, the new generation of GC, when the new generation of GC, unable to meet the allocation of memory space requirements, the entire space and method area for GC (full GC). And the Cenozoic can be divided into: a Eden space and two pieces of the same size Survivor Space (s0,s1 or from Survivor and to Survivor) are seen in the official figure. The e-and S-districts in the Cenozoic have different responsibilities.
  • E-ZONE: The GC triggers a more frequent area, stores the new object, and almost all of the objects go through the e area, and if the GC still has surviving objects, place the surviving objects in the S area.
  • S-Zone: The S-area serves as the cache for the Eden and old (older ages). It is an instance of the active object that can be transferred to the old age.
• Old age: Used to store multiple generations of GC still alive objects, such as cached objects. New objects may also be directly into the old age, there are two main cases: ①. large objects, which can be set by the start parameter -xx:pretenuresizethreshold=1024 ( in bytes, by default 0) to represent more than the new generation, are allocated directly in the old age. ②. a large Array object that has no reference to the outer object in the tangent array.
  
• Regardless of how the Java heap is divided, the goal is to better reclaim memory, or to allocate memory faster, and the Java heap is in a discontinuous space on the physical space, but logically contiguous. The virtual machine heap memory space is extensible and can be controlled by-XMX and-xms, and throws a OutOfMemoryError exception if the heap cannot allocate memory space and the heap can no longer scale to the amount.

5. Method Zone (Mehod area)

The method area, like the heap, is also a thread-shared area, which is primarily used to store data such as class information, constants, static variables, and timely compiler-compiled code that are loaded by virtual machines, and are not part of the heap. In relative terms, GC behavior is relatively rare in this area, but not in the case of some descriptions of the permanent generation of GC. For Sun's hotspot virtual machines. GC also recycles this area, where recycling is primarily a constant pool collection and unloading of classes.

If the subdivision method area contains a run-time pool (runtime Constant pool), it mainly stores the description information of the version, field, method, interface, etc. in the class file. Another piece of information is that the constant table (Constant_pool table) is used to hold constants that are known during the compilation period, which is stored in the class load backward-in method area (permanent generation). However, the Java language does not require constants to enter the method area constant pool only if the content of the const table of the class is pre-set at compile time, and the new content can be put into Chang (most typically the String.intern () method) .

Actual combat OutOfMemoryError:

In addition to the program counter, the other in the Vmspec described the generation of OutOfMemoryError (hereinafter called Oom), then we simulated the actual situation, through a few simple code, so that the corresponding area of the Oom to create an error to deepen understanding, Some memory-related virtual machine parameters are also introduced.

1.Java Heap:

The Java heap holds object instances, so you can create an Oom exception by constantly building objects and ensuring that gcroots can have a path between objects. The test restricts the Java heap size to 20M, is not extensible, and allows the virtual machine to dump the memory image for analysis when an oom exception occurs through the parameter-xx:+heapdumponoutofmemoryerror.

Code:

PackageCOM.LP.ECJTU;ImportJava.util.ArrayList;PublicClass Jvmtestdemo_heap {public static void main ( String[]args) {java.util.list<oomobject>list = new arraylist<oomobject>< Span style= "color: #000000;" >(); while (truenew Oomobject ());}}} /** * vmargs:-xms20m-xmx20m-xx:+ Heapdumponoutofmemoryerror *  @author  Administrator * Span style= "color: #008000;" >*/class oomobject{}     

Operation Result:
Java.lang.OutOfMemoryError:JavaheapspaceDumpingheaptojava_pid3404.hprof ... Heapdumpfilecreated[22045981bytesin0.663secs]

Garbage collection GC (garbagecollection, hereinafter referred to as GC):

The GC's history is much longer than in Java, and was born in 1960 at the MIT Lisp (a real memory winter allocation and garbage collection) language. When Lisp is in embryonic time, there are 3 things people need to do in a GC:

1. Which memory needs to be recycled
2. When to recycle
3. How to Recycle

Summary: Where the program counter, VM stack, the local method stack with the thread, and out of the thread, the frame in the stack with the method of entry and exit, methodically carried out the stack and into the stack operation; How much memory is allocated per frame, is basically known when the class file is generated (some optimizations may be made by JIT dynamic late compilation, but in general it can be seen as a compile time
, so there is a high level of certainty in the allocation and recycling of memory in these areas, so there is no need to think too much about recycling in these areas. the Java heap and the method area (including the run-time pool) are different, and we have to wait until the program actually runs to know that those objects are created, and that the collection and allocation of the memory is dynamic.