JVM exploration-Memory Management (2), jvm exploration Memory Management

JVM exploration-Memory Management (2), jvm exploration Memory Management

In the previous article, we introduced the memory structure managed by JVM, that is, the Run-Time Data Areas. Now we will introduce JVM memory allocation and recovery.
Static Memory Allocation and dynamic memory allocation

JVM memory allocation can be divided into two types: Static Memory Allocation and dynamic memory allocation, which correspond to basic types of memory allocation and object memory allocation;
1. Static Memory Allocation
Static Memory allocation has been determined during compilation. When the program is loaded, the JVM allocates the memory once and will not change. These include local variables (basic data types), class variables (basic data types), and object references in the method; the local variables in the method are stored in the local variable table of the Java stack. The method execution ends the stack frame out of the stack, and the local variables will also reclaim the memory space; the class variables are stored in the method area, and the memory recovery time here is uncertain.
2. Dynamic Memory Allocation
The memory allocated to objects in Java is dynamically allocated. The size of the object's storage space cannot be determined during compilation, but the memory space can be allocated only when an object is created, the memory space can be recycled only when the object is no longer referenced. Objects are stored in the heap, and the memory space of those objects that are not referenced is cleared only when GC is triggered;
See the following code snippet;
Public class Test {
Byte [] bytes = new byte [1024*1024*5];
Long a = 1000;
Public static void main (String [] args ){
Long B = 2;
Byte [] base = new byte [1024*1024*1];
Test t = new Test ();
}
}
Bytes: the Array Memory is allocated in the heap, but the method zone is referenced by the storage. JVM will use dynamic memory allocation, during compilation, it cannot be determined that the bucket is allocated to bytes only when the test object is created. GC can recycle the object only when the object is not referenced;
A: It is a class variable and the basic data type. When Test is compiled and loaded, the storage space is determined and stored in the method area;
B: It is the basic data type of the method. Only when this method is executed will the storage space be allocated to the local variable table of the stack frame. After the method is executed, the stack frame will be released, the storage space in the local variable table is also recycled;
Base: local variable. It is allocated storage space in the heap only when the statement is executed. GC can recycle the referenced local variable table stored in the stack frame if it is not referenced;
T: objects are allocated storage space in the heap just like arrays, but object references are stored in the stack frame local variable table. GC can reclaim the storage space only when the objects are not referenced;

Determine whether it can be recycled
Next, we will introduce the JVM memory recycling. The first thing JVM needs to do during garbage collection is to determine which garbage is used before it can recycle the memory space occupied by garbage. As we have said above, if an object is recycled on the premise that the object is not referenced by an active object, how does the JVM know whether an object is referenced.
There are two algorithms used to determine whether an object is referenced: The reference counting algorithm and the root search algorithm;
Reference Counting: adds a Reference counter to an object. When a Reference counter is added to an object and the Reference disappears, the counter is reduced by one, if the counter is 0, this object is not referenced. This algorithm is used in less programming languages, such as python.
Root search algorithm (GC Roots Tracing): Java, C #, and so on use this algorithm to determine whether an object is alive. This algorithm starts from a series of objects whose names are "GC Roots, the search starts from these nodes and goes through the Reference Chain path. This object is unavailable when no Reference Chain exists between the object and GC Roots, this unavailable object will be recycled.

1, 2, and 3 are active objects, and the three objects are referenced in the GC Roots.
4. 5 is the dead object, and the object cannot be reached by GC Roots

Java, which can be used as GC Roots objects include:
Objects referenced in the local variable table in the stack frame of the Virtual Machine Stack
Reference object in local method Stack
Objects referenced by constants in the method Area
Objects referenced by class static attributes in the Method Area
Class Object Reference

Garbage collection Algorithm
1. Mark-Sweep (Mark-Sweep): the algorithm is divided into two stages: Mark and clear. Based on the method described above, the algorithm determines whether an object can be recycled, if it can be recycled, it will be marked and recycled after all objects are marked;
2. Copy algorithm (Copying) the copy collection algorithm divides the memory into two blocks of space with the same capacity, each using only one fast, when the system runs out quickly, it copies the surviving objects to another block and recycles the previously used memory space.
3. Mark-Compact (Mark-Compact), which is the same as the Mark-clearing algorithm, first marks the objects to be cleansed. The difference is that, next, he moves the surviving object to one end, and then recycles the memory space outside the boundary of the end.
4. The generation Collection algorithm (Generational Collection) is used by many virtual machines, such as HotSpot. The algorithm divides objects into several regions based on different lifecycles. For example, HotSpot divides the heap into the new generation and the old generation, and then uses a suitable collection algorithm based on the characteristics of each region. Generally, the life cycle of new generation objects is relatively short, so the replication algorithm is used. In the old age, objects have a long life cycle. Therefore, it is more suitable to use the tag-clean and tag-Sort algorithms for collection.

First Article address: Solinx

Http://www.solinx.co/archives/45

How to manage jvm memory

Typical settings:
• Java-Xmx3550m-Xms3550m-Xmn2g-Xss128k
-Xmx3550m: sets the maximum available JVM memory to 3550 MB.
-Xms3550m: Set JVM to enable the memory to be 3550 MB. This value can be set to the same as-Xmx to avoid JVM re-allocating memory after each garbage collection.
-Xmn2g: Set the young generation to 2 GB. Total heap size = size of the young generation + size of the old generation + size of the persistent generation. The permanent generation usually has a fixed size of 64 m. Therefore, increasing the size of the young generation will reduce the size of the old generation. This value has a great impact on the system performance. Sun officially recommends 3/8 of the total heap configuration.
-Xss128k: Set the stack size of each thread. After JDK 256, the size of each thread stack is 1 MB, and the size of each previous thread stack is K. The memory size required for more application threads is adjusted. Reduce this value to generate more threads in the same physical memory. However, the operating system still has a limit on the number of threads in a process. It cannot be generated infinitely. The experience is between 3000 and ~ About 5000.
• Java-Xmx3550m-Xms3550m-Xss128k-XX: NewRatio = 4-XX: Export vorratio = 4-XX: MaxPermSize = 16 m-XX: MaxTenuringThreshold = 0
-XX: NewRatio = 4: Set the ratio of the young generation (including Eden and two region vor regions) to the old generation (excluding the permanent generation ). If this parameter is set to 4, the ratio of the young generation to the old generation is, and the young generation accounts for 1/5 of the entire stack.
-XX: Region vorratio = 4: Set the ratio of Eden to region vor in the young generation. If this parameter is set to 4, the ratio of two vor zones to One Eden zone is, and one vor zone accounts for 1/6 of the young generation.
-XX: MaxPermSize = 16 m: sets the persistent generation size to 16 m.
-XX: MaxTenuringThreshold = 0: sets the maximum age of spam. If it is set to 0, the young generation object directly enters the old generation without going through the VOR area. For applications with many older generations, the efficiency can be improved. If this value is set to a greater value, the young generation object will be copied multiple times in the same vor area, which can increase the survival time of the young generation object, added an overview of being recycled in the young generation.

How to manage java JVM virtual memory

JVM memory management: goes deep into the garbage collector and memory allocation policies
There is a wall between Java and C ++ that is surrounded by the dynamic memory allocation and garbage collection technology. The people who look at it want to go in, but the people inside the wall want to come up with it.
Overview: when talking about Garbage Collection (GC), most people regard this technology as a companion product of the Java language. In fact, GC history is far older than Java. The Lisp, which was born in 1960 by MIT, is the first language that truly uses the dynamic memory allocation and garbage collection technology. When Lisp is still in the embryo, people are thinking about three things GC needs to do: What memory needs to be recycled? When will it be recycled? How to recycle it?
Call back the time from October 11 to the present and return to the familiar Java language. The first chapter of this article introduces each part of the Java memory runtime region, where the program counters, VM stacks, and local method stacks are generated with threads and destroyed with threads; frames in the stack are methodically launched into the stack as the method enters and exits; the amount of memory allocated in each frame is basically known when the Class file is generated (it may be optimized by JIT dynamic late compilation, but it can be considered as known during the compilation period ), therefore, the memory allocation and recovery in these regions are highly deterministic, so there is no need to consider the issue of recovery too much in these regions. The Java heap and the method area (including the runtime frequent pool) are different. We must wait until the program is actually running to know which objects will be created, the allocation and recovery of this part of memory are dynamic. The "Memory" Allocation and recovery we will discuss later only refer to this part of memory.
Reference Counting)
The original idea is that many textbooks use the following algorithm to determine whether an object is alive: Add a reference counter to the object. When there is a place to reference it, add 1 to the counter. When the reference fails, the counter minus 1. Objects whose counter is 0 at any time cannot be used again.
Objectively speaking, the reference counting algorithm is easy to implement and highly efficient in determination. In most cases, it is a good algorithm, but the reference counting algorithm cannot solve the problem of object circular reference. For example, the objects A and B have fields B and a, respectively. B = B and B. a = A. In addition, the two objects have no reference. In fact, the two objects cannot be accessed again, but the reference counting algorithm cannot recycle them.
Root search algorithm (GC Roots Tracing)
In actual production languages (Java, C #, and even the previously mentioned Lisp), the root search algorithm is used to determine whether an object is alive. The basic idea of the algorithm is to perform a downward search through a series of points called "GC Roots" as the starting point. When an object is connected to GC Roots, there is no Reference Chain, it proves that this object is unavailable. In Java, GC Roots includes:
1. Reference in VM stack (local variable in frame)
2. Static reference in the Method Area
3. References in JNI (the Native method in general)
Survival or death?