Java Virtual Machine (3) Automatic Memory Management Mechanism

Java Virtual Machine (3) Automatic Memory Management Mechanism
Summary

In the Java technical system, automatic memory management can be attributed to two problems automatically:Allocate memory to objects and reclaim the memory allocated to objects..
 

This article focuses on allocating memory to objects. The memory allocation of objects, in the larger direction, is allocated on the heap. However, in some cases, stack and TLAB are allocated. Therefore, the allocation rules are not fixed. The details depend on which GC combination is used and the memory-related parameter settings in the virtual machine.

 

 

This article describes several of the most common memory allocation rules and verifies these rules with code. Common memory allocation rules include the following: objects are preferentially allocated to Eden. large objects are directly allocated to objects that have long-term survival in the old age. The age of dynamic objects in the old age is determined first.

 

Modern Commercial virtual machines divide Java heaps into new and old generations. In the new generation, Replication Algorithms are generally used. In the old age, the tag-sorting algorithm is generally used.

The heap space of the new generation is divided into a large Eden space and two small volume vor spaces, as shown in figure. Each time, only Eden and one of them are used as a replica VOR (because the replication algorithm is used, so another region VOR is used as a reserved region ). By default, the size ratio of Eden to VOR is, which means that the available memory space of each new generation is 90% of the capacity of the new generation, and only 10% of the memory will be "wasted. Of course, 98% of objects can be recycled only in general scenarios. We cannot ensure that no more than 10% of objects are retained at a time. When vor space is insufficient, you need to rely on other memory (this refers to the old age) for allocation guarantee. In general, the GC policy is as follows:

To put it bluntly, let's start with the text below.

Objects are preferentially allocated in Eden.

Run the following code first, and then analyze it with logs.Note the Virtual Machine startup parameters that need to be set during execution at the beginning of the following code. These parameters have a direct impact on the experiment results. Do not ignore them when debugging the code.This example introduces more details. The repeated content in the following examples is not described in detail.

public class TestGC1 {       private static final int _1MB = 1024*1024;       /**       * VM ARGS: -verbose:gc - Xms20m -Xmx20m -Xmn10m - XX:SurvivorRatio=8 -XX:+PrintGCDetails       */       public static void testAllocation(){             byte[] allocation1, allocation2,allocation3 ,allocation4;            allocation1 = new byte [2 * _1MB];            allocation2 = new byte [2 * _1MB];            allocation3 = new byte [2 * _1MB];            allocation4 = new byte [4 * _1MB];      }       public static void main(String[] args) {             testAllocation();      }}

View output logs

 

First, explain the meaning of each parameter:
-Verbose: gc indicates the output of GC in the Virtual Machine (Red box)
-Xms20m indicates the initial heap value.
-Xmx20m indicates the maximum initial heap size (when the values of-Xms and-Xmx are equal, the heap space is 20 m and cannot be expanded)
-Xmn10m indicates the heap size in the old age.
-XX: Region vorratio = 8 indicates that the space ratio of the Eden and region vor areas in the new generation is.
-XX: + PrintGCDetails: prints GC details (Blue Box)

In the testAllocation () method, try to allocate 3 2 MB objects and 1 4 MB objects. A Minor GC occurs when allocation4 objects are allocated. For details, see the log (Red box), For an explanation of each number, refer to the http://blog.csdn.net/alivetime/article/details/6895537. The GC results showed that the new generation was changed from 6 kb to 149KB, while the total memory usage was almost not reduced (because allocation1, allocation2, allocation3 are still alive ). The reason for this Minor GC is that when allocation4 is allocated memory, it is found that Eden has been occupied 6 MB, and the remaining 2 MB is not allocated, so Minor GC occurs.
During GC, the virtual machine found that three 2 MB objects could not be stored in memory or space, so they had to be transferred to the old age in advance through the allocation guarantee mechanism.
At this time, the space in the old age is 10 MB enough to allocate 3 2 MB objects, so Full GC is not executed.
Next, the virtual machine will check whether the HandlePromotionFailure setting allows guarantee failure. The default value is true. Therefore, Minor GC is executed. The execution process is shown in the red line header.

After GC, the 4 MB allocation4 object is successfully allocated to Eden. Therefore, the execution result is that Eden occupies 4 MB, VOR space, and 6 MB in the old age.

Large objects directly enter the Old AgeFirst run the code and output the log

public class TestGC2 {       private static final int _1MB = 1024*1024;       /**       * VM ARGS: - verbose:gc - Xms20m -Xmx20m - Xmn10m - XX:SurvivorRatio=8 - XX:+PrintGCDetails       * - XX:PretenureSizeThreshold=3145728       */       public static void testPretenureSizeThreshold(){             byte [] allocation;            allocation = new byte [4 * _1MB];      }       public static void main(String[] args) {             testPretenureSizeThreshold();      }}

Output GC logs as follows: Heap def new generation total 9216 K, used 507 K [0x315e0000, 0x31fe0000, 0x31fe0000) eden space 8192 K, 6% used [0x315e0000, 0x00005ef18, 0x31de0000) from space 1024 K, 0% used [0x31de0000, 0x31de0000, 0x31ee0000) to space 1024 K, 0% used [0x31ee0000, 0x31ee0000, 0x31fe0000) tenured generation total 10240 K, used 4096 K [hour, 0x329e0000, 0x329e0000) The space 10240 K, 40% used[0x31fe0000, 0x323e0010, 0x323e0200, 0x329e0000)

The virtual machine provides the-XX: PretenureSizeThreshold parameter, so that objects larger than this setting are directly allocated to the old age. Therefore, in the testPretenureSizeThreshold () method, 4 MB allocation objects are allocated to the old age. LogsRed partProve this

Long-lived objects enter the Old Age

In order to identify which objects should be placed in the new generation and which objects should be put in the old age, the virtual machine defines an object age technician for each object.
If the object is still alive after being born in Eden and after the first Minor GC and can be accommodated by the same vor, it will be moved to the same vor space and set the age of the object to 1. every time a MinorGC occurs in a vor, the age increases by one year. When the age increases to a certain degree (15 years by default), the object is promoted to the old age. The age threshold for objects to be promoted to the old age can be set by the-XX: MaxTenuringThreshold parameter.

Run the following code and output the GC log with MaxTenuringThreshold = 1 and MaxTenuringThreshold = 15 respectively.

public class TestGC3 {       private static final int _1MB = 1024*1024;       /**       * VM ARGS: - verbose:gc - Xms20m -Xmx20m - Xmn10m - XX:SurvivorRatio=8 - XX:+PrintTenuringDistribution       * - XX:MaxTenuringThreshold=1 - XX:+PrintGCDetails       */       public static void testMaxTenuringThreshold(){             byte [] allocation1, allocation2,allocation3 ;            allocation1 = new byte [ _1MB / 4];            allocation2 = new byte [ _1MB * 4];            allocation3 = new byte [ _1MB * 4];            allocation3 = null ;            allocation3 = new byte [ _1MB * 4];      }       public static void main(String[] args) {             testMaxTenuringThreshold();      }

Run the output log with MaxTenuringThreshold = 1

[GC [DefNew Desired into vor size 524288 bytes, new threshold 1 (max 1)-age 1: 415288 bytes, 415288 total: 4695 K-> 405 K (9216 K ), 0.0064338 secs] 4695 K-> 4501 K (19456 K), 0.0064885 secs] [Times: user = 0.00 sys = 0.00, real = 0.00 secs] [GC [DefNew Desired limit vor size 524288 bytes, new threshold 1 (max 1)-age 1: 136 bytes, 136 total: 4665 K-> 0 K (9216 K), 0.0013172 secs] 8761 K-> 4501 K (19456 K), 0.0013602 secs] [Times: user = 0.00 sys = 0.02, real = 0.02 secs] Heap def new generation total 9216 K, used 4260 K [0x315e0000, 0x31fe0000, 0x31fe0000) eden space 8192 K, 52% used [0x315e0000, 0x31a08fe0, 0x31de0000) From space 1024 K, 0% used[0x31de0000, 0x31de0088, 0x31ee0000) to space 1024 K, 0% used [0x31ee0000, 0x31ee0000, 0x31fe0000) tenured generation total 10240 K, used 4501 K [0x31fe0000, Hangzhou, Hangzhou) The space 10240 K, 43% used[0x31fe0000, 0x32445578, 0x32445600, 0x329e0000)

Run the output log with MaxTenuringThreshold = 15

[GC [DefNew Desired into vor size 524288 bytes, new threshold 15 (max 15)-age 1: 415288 bytes, 415288 total: 4695 K-> 405 K (9216 K ), 0.0064799 secs] 4695 K-> 4501 K (19456 K), 0.0065357 secs] [Times: user = 0.00 sys = 0.00, real = 0.00 secs] [GC [DefNew Desired limit vor size 524288 bytes, new threshold 15 (max 15)-age 1: 136 bytes, 136 total-age 2: 415080 bytes, 415216 total: 4665 K-> 405 K (9216 K), 0.0011127 secs] 8761 K-> 4501 K (19456 K), 0.0011722 secs] [Times: user = 0.01 sys = 0.00, real = 0.02 secs] Heap def new generation total 9216 K, used 4665 K [0x315e0000, 0x31fe0000, 0x31fe0000) eden space 8192 K, 52% used [0x315e0000, 0x31a08fe0, 0x31de0000) From space 1024 K, 39% used[0x31de0000, primary, 0x31ee0000) to space 1024 K, 0% used [0x31ee0000, 0x31ee0000, 0x31fe0000) tenured generation total 10240 K, used 4096 K [0x31fe0000, Primary, Secondary) The space 10240 K, 40% used[0x31fe0000, 0x323e0010, 0x323e0200, 0x329e0000)

In method testMaxTenuringThreshold (), the allocation1 object requires KB of memory space. When MaxTenuringThreshold = 1, The allocation1 object enters the old age when the second GC occurs, and the memory vor space of the new generation changes to 0 kb.
When MaxTenuringThreshold = 15, the allocation1 object remains in the new generation when GC occurs for the second time, and the new generation of zoovor space becomes 404KB.

Dynamic Object age determination

In order to better adapt to the memory of different programs, virtual machines do not always require that the object age must reach MaxTenuringThreshold to be promoted to the old age. If the total size of all objects of the same age in the primary vor space is greater than half of the primary vor space, objects of the same age or age can enter the old age without waiting for the age specified by MaxTenuringThreshold.
Run the following code and output the GC log.

 

public class TestGC4 {       private static final int _1MB = 1024*1024;       /**       * VM ARGS: - verbose:gc - Xms20m -Xmx20m - Xmn10m - XX:SurvivorRatio=8 - XX:+PrintTenuringDistribution       * - XX:MaxTenuringThreshold=1 - XX:+PrintGCDetails       */       public static void testMaxTenuringThreshold(){             byte [] allocation1, allocation2,allocation3 ,allocation4;            allocation1 = new byte [ _1MB / 4];            allocation2 = new byte [ _1MB / 4];            allocation3 = new byte [ _1MB * 4];            allocation4 = new byte [ _1MB * 4];            allocation4 = null ;            allocation4 = new byte [ _1MB * 4];      }       public static void main(String[] args) {             testMaxTenuringThreshold();      }}

Output GC logs

[GC [DefNew Desired into vor size 524288 bytes, new threshold 1 (max 15)-age 1: 677448 bytes, 677448 total: 4951 K-> 661 K (9216 K ), 0.0066603 secs] 4951 K-> 4757 K (19456 K), 0.0067187 secs] [Times: user = 0.00 sys = 0.00, real = 0.00 secs] [GC [DefNew Desired limit vor size 524288 bytes, new threshold 15 (max 15)-age 1: 136 bytes, 136 total: 4921 K-> 0 K (9216 K), 0.0014790 secs] 9017 K-> 4757 K (19456 K), 0.0015298 secs] [Times: user = 0.00 sys = 0.00, real = 0.00 secs] Heap def new generation total 9216 K, used 4260 K [0x315e0000, 0x31fe0000, 0x31fe0000) eden space 8192 K, 52% used [0x315e0000, 0x31a08fe0, 0x31de0000) From space 1024 K, 0% used[0x31de0000, 0x31de0088, 0x31ee0000) to space 1024 K, 0% used [0x31ee0000, 0x31ee0000, 0x31fe0000) tenured generation total 10240 K, used 4757 K [0x31fe0000, Hangzhou, Hangzhou) The space 10240 K, 46% used [0x31fe0000, 0x32485588, 0x32485600, 0x329e0000)

In the log, we found that the usage of the VOR space in the region is 0, that is to say, the allocation1 and allocation2 objects are all in the old age, instead of waiting until the age of 15.