memory allocation and recovery policy

　The automatic memory management advocated in the Java technology architecture can ultimately be attributed to automating two problems: allocating memory to objects and reclaiming memory allocated to objects.

The memory allocation of an object is allocated on the heap (but it may also be JIT-compiled to be split into scalar types and indirectly allocated on the stack), the object is primarily allocated on the new generation of Eden, and if the local thread allocation buffer is started, it will be allocated on Tlab by thread precedence. A few cases may also be allocated directly in the old age, and the rules of allocation are not completely fixed, depending on which garbage collector combination is currently being used, and the settings of memory-related parameters in the virtual machine.

The following describes the most common memory allocation rules in the set and validates them through code. The code in this section runs with the client mode virtual machine during testing and does not manually specify the collector combination, in other words, the memory allocation and recycling policy that is validated using the serial/serial old collector (the rules of the parnew/serial old combination are also basically consistent).

1. Object Precedence in Eden assignment

In most cases, objects are allocated in the Cenozoic Eden region. When the Eden Zone does not have enough space allocated, the virtual machine will initiate a minor GC. The virtual machine provides-xx:+printgcdetails this collector log parameter to tell the virtual machine to print the memory recycle log when the garbage collection behavior occurs, and to output the allocation of the current memory regions when the process exits. In real-world applications, memory recycling logs are typically printed to a file and analyzed by the log tool.

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];//appears once minor GC    }

Operation Result:

[GC [Defnew:6487k->152k (9216K), 0.0041641 secs] 6487K-> 6296K (19456K), 0.0042253 secs] [times:user=0.02 sys=0.00, real=0.00 secs] Heap def New generation Total 9216K, used 44 12K [0x326e0000, 0x330e0000, 0x330e0000) Eden Space 8192K, 52% used [0x326e0000, 0X32B08FE0, 0x32ee0000] from space 102 4 K, 14% used [0x32fe0000, 0x330062b0, 0x330e0000) to space 1024K, 0% used [0x32ee0000, 0x32ee0000, 0x32fe0000] tenured Generation Total 10240K, used 6144K [0x330e0000, 0x33ae0000, 0x33ae0000) The space 10240K, 60% used [0x330e0000, 0x33 6e0030, 0x336e0200, 0x33ae0000) compacting Perm gen Total 12288K, used 375K [0x33ae0000, 0x346e0000, 0x37ae0000) the Space 12288K, 3% used [0x33ae0000, 0x33b3dcb0, 0x33b3de00, 0x346e0000) Ro space 10240K, 54% used [0x37ae0000, 0x3805d 9f8, 0x3805da00, 0x384e0000) RW space 12288K, 55% used [0x384e0000, 0x38b813f8, 0x38b81400, 0x390e0000)  
  

　Attempt to allocate 3 2MB and a 4MB object, at run time through the-xms20m,-xmx20m and-xmn10m These 3 parameters limit Java heap size is 20M, and not extensible, where 10MB is assigned to the new generation, the remaining 10M is allocated to the old age. -Xx:survivorratio=8 determines the space ratio of the new generation of Eden and survivor area is 8:1, from the operation results can be seen "Eden Space 8192K, from space 1024K, to space 1024K" information, The total free space for the new generation is 9216KB (total capacity of Eden Zone + 1 survivor zone).

A minor GC occurs when executing a statement that allocates a Allocation4 object in Testallocation (), and the result of this GC is that the Cenozoic changes from 6487K to 152K, while the total memory footprint is almost no less (because Allocation1, 2, 33 objects are surviving virtual machines with little or no recoverable objects found. This GC occurs because the Allocation4 allocates the required 4MB of memory, it is found that the Eden area is already occupied 6MB, the remaining space is not enough to allocate 4MB, so minor GC occurs. During GC, the virtual machine found that 3 2MB objects were not fully placed in the Survivor space (survivor only 1MB), so it had to be transferred to the old age by the allocation guarantee mechanism.

At the end of this GC, 4MB Allocation4 objects were successfully allocated to Eden. So the result of the program execution is that Eden occupies 4MB (occupied by Allocation4), survivor Idle, the old age is occupied 6MB (allocation1,2,3 occupancy).

What's different about minor and full GC?

New Generation GC (Minor GC): Refers to the garbage collection action occurring in the new generation, because most Java objects have the characteristics of dying, so Minor GC is very frequent, the general recovery speed is relatively fast.

Old age GC (Major gc/full GC): Refers to GC, which occurs in the old age, Major GC, often accompanied at least once minor GC (but not absolute, in the parallel scavenge collector's collection strategy is directly Major GC's policy selection process). Major GC is typically 10 times times slower than the minor GC.

2. Large objects directly into the old age

A large object is a Java object that requires a lot of contiguous memory space, the most typical of which is the long string and array (byte[] arrays are typical large objects). Large objects are bad news for the memory allocation of virtual machines (worse, a bunch of short-lived objects that are dying in the face of death, should be avoided when writing programs), often large objects tend to lead to memory and a lot of space in advance to trigger garbage collection to get enough contiguous space to accommodate large objects.

The virtual machine provides a-xx:pretenuresizethreshold parameter that allows an object larger than this setting to be allocated directly into the old age. This avoids a large amount of memory duplication between the Eden Zone and the two survivor zones.

/**     *-verbose:gc-xms20m-xmx20m-xmn10m-xx:survivorratio=8-xx:+printgcdetails     *-XX: pretenuresizethreshold=3145728     *    /public static void Testpretenuresizethreshold () {        byte[] allocation;        allocation = new BYTE[4*_1MB];    } 

Operation Result:

Heap def New Generation total   9216K, used 671K [0x046a0000, 0x050a0000, 0x050a0000)   Eden Space 8192K,   8% used [0x046a0000, 0x04747e88, 0x04ea0000]   From Space 1024K,   0% used [0x04ea0000, 0x04ea0000, 0x04fa0000]   to   space 1024K,   0% used [0x04fa0000, 0x04fa0000, 0x050a0000) tenured generation total   10240K, used 4096K [0x050a0000, 0x05aa0000, 0x05aa0000)   the Space 10240K,  40% used [0x050a0000, 0x054a0010, 0x054a0200, 0x05aa0000)   compacting Perm Gen Total  12288K , used 2130K [0x05aa0000, 0x066a0000, 0x09aa0000) The   space 12288K,  17% used [0x05aa0000, 0X05CB49B8, 0x05cb4a0 0, 0x066a0000) No GKFX spaces configured. 

We can see that the Eden space is almost unused, while the old 10MB space is used 40%, that is, the 4MB allocation object is directly allocated to the old age, because Pretenuresizethreshold is set to 3MB, As a result, objects over 3MB will be allocated directly in the old age.

3. Long-term survival of the target will enter the old age

Virtual machines Use the idea of generational collection to manage memory, and memory recycling must identify which objects should be placed in the new generation and which should be in the old age. To do this, the virtual machine defines an object age counter for each object. If the object is still alive after Eden was born and after the first minor GC, and can be accommodated by survivor, it is moved to survivor space and the object age is set to 1. The object has not survived a minor GC in the Survivor area, the age increases by 1, and when its age increases to a certain extent (by default, 15) _, it is promoted to the old age. The age threshold for the promotion of the object to the old era can be set by the parameter-xx:maxtenuringthreshold.   

/**    * VM Args:-verbose:gc-xms20m-xmx20m-xmn10m-xx:survivorratio=8-xx:+printgcdetails    *-XX: Maxtenuringthreshold=1    *    /public static void Testtenuringthreshold () {        byte[] allocation1,allocation2, Allocation3;        Allocation1 = new BYTE[_1MB/4];        Allocation2 = new BYTE[4*_1MB];        Allocation3 = new BYTE[4*_1MB];        Allocation3 = null;        Allocation3 = new BYTE[4*_1MB];    }

:

[GC [defnewdesired Survivor size 524288 bytes, new threshold 1 (max 1)-age 1:420200 Bytes, 420200 total:4859k ->410k (9216K), 0.0042347 secs] 4859k->4506k (19456K), 0.0042967 secs] [times:user=0.02 sys=0.00, real=0.00 secs] [G C [defnewdesired Survivor size 524288 bytes, new threshold 1 (max 1): 4506k->0k (9216K), 0.0008751 secs] 8602k->4506k (19456K), 0.0009284 secs] [times:user=0.00 sys=0.00, real=0.00 secs] Heap def New generation total 9216K, used 4178K [0   x04540000, 0x04f40000, 0x04f40000) Eden Space 8192K, 51% used [0x04540000, 0x04954830, 0x04d40000] from space 1024K, 0% used [0x04d40000, 0x04d40000, 0x04e40000) to space 1024K, 0% used [0x04e40000, 0x04e40000, 0x04f40000] tenured gen Eration total 10240K, used 4506K [0x04f40000, 0x05940000, 0x05940000) The space 10240K, 44% used [0x04f40000, 0X053A6 978, 0x053a6a00, 0x05940000) compacting Perm gen Total 12288K, used 2137K [0x05940000, 0x06540000, 0x09940000) the SPAC E 12288K, 17% used [0x05940000, 0x05b56580, 0x05b56600, 0x06540000) No GKFX spaces configured. 

[GC [defnewdesired Survivor size 524288 bytes, new threshold (max)-age 1:420200 Bytes, 420200 total:485 9k->410k (9216K), 0.0069588 secs] 4859k->4506k (19456K), 0.0070540 secs] [times:user=0.00 sys=0.00, real=0.01 secs] [GC [defnewdesired Survivor size 524288 bytes, new threshold (max)-age 2:420056 Bytes, 420056 total:450 6k->410k (9216K), 0.0012592 secs] 8602k->4506k (19456K), 0.0013433 secs] [times:user=0.00 sys=0.00, real=0.00 secs] Heap def New Generation total 9216K, used 4588K [0x044e0000, 0x04ee0000, 0x04ee0000) Eden Space 8192K, 51% used [0x044 e0000, 0x048f4830, 0x04ce0000) from space 1024K, 40% used [0x04ce0000, 0x04d468d8, 0x04de0000] to space 1024K, 0% u sed [0x04de0000, 0x04de0000, 0x04ee0000) tenured generation total 10240K, used 4096K [0x04ee0000, 0x058e0000, 0x058e0000 ) The space 10240K, 40% used [0x04ee0000, 0x052e0010, 0x052e0200, 0x058e0000) compacting Perm gen Total 12288K, used 2 137K [0x058e0000, 0x064e00XX, 0x098e0000) The space 12288K, 17% used [0x058e0000, 0x05af6580, 0x05af6600, 0x064e0000) No GKFX spaces configured.

The Allocation1 object in this method requires 256KB of memory space, survivor space can be accommodated. When Maxtenuringthreshold=1, the Allocation1 object enters the old age when the second GC occurs, and the new generation of used memory GC becomes 0KB very cleanly. While Maxtenuringthreshold=15, the second GC occurs, the Allocation1 object remains in the Cenozoic survivor space, when the new generation still has 410KB of space occupied.

4. Dynamic Object Age Determination

In order to better adapt to the memory situation of different programs, the virtual machine does not always require the age of the object must reach maxtenuringthreshold to be promoted to the old age, if the same age in the survivor space of all object size is more than half of the survivor space, Objects older than or equal to that age can go straight into the old age without waiting for the ages required in the maxtenuringthreshold.

/**     * VM Args:-verbose:gc-xms20m-xmx20m-xmn10m-xx:survivorratio=8     *-xx:maxtenuringthreshold=15-xx:+ Printtenuringdistribution     *    /public static void TestTenuringThreshold2 () {        byte[] allocation1, Allocation2,allocation3,allocation4;        Allocation1 = new BYTE[_1MB/4];        Allocation2 = new BYTE[_1MB/4];        Allocation3 = new BYTE[4*_1MB];        Allocation4 = new BYTE[4*_1MB];        Allocation4 = null;        Allocation4 = new BYTE[4*_1MB];    } 

Operation Result:

[GC [defnewdesired Survivor size 524288 bytes, new threshold 1 (max)-age 1:682360 Bytes, 682360 total:5115 k->666k (9216K), 0.0068333 secs] 5115k->4762k (19456K), 0.0069434 secs] [times:user=0.01 sys=0.00, real=0.01 secs] [ GC [defnewdesired Survivor size 524288 bytes, new threshold (max): 4762k->0k (9216K), 0.0015284 secs] 8858k->47  62K (19456K), 0.0016157 secs] [times:user=0.00 sys=0.00, real=0.00 secs] Heap def New generation total 9216K, used 4178K    [0x04470000, 0x04e70000, 0x04e70000) Eden Space 8192K, 51% used [0x04470000, 0x04884830, 0x04c70000] from space 1024K, 0% used [0x04c70000, 0x04c70000, 0x04d70000) to space 1024K, 0% used [0x04d70000, 0x04d70000, 0x04e70000] tenured Generation Total 10240K, used 4762K [0x04e70000, 0x05870000, 0x05870000) The space 10240K, 46% used [0x04e70000, 0x05 3168f8, 0x05316a00, 0x05870000) compacting Perm gen Total 12288K, used 2137K [0x05870000, 0x06470000, 0x09870000) the S Pace 12288K, 17% used [0x05870000, 0x05a86580, 0x05a86600, 0x06470000) No GKFX spaces configured.  

Survivor occupancy in the results was still 0%, while the old age was 6% higher than expected, meaning Allocation1,allocation2 objects were directly into the old age, without waiting for the 15-year-old critical age. Because these two objects add up to reach 512KB, and they are the same year, meet the same year the object reaches survivor space half the rules. We just need to annotate the new operation of an object, and we'll see that the other one won't be promoted to the old age.

5. Space Allocation Guarantee

When the minor GC occurs, the virtual opportunity detects whether the average size of each promotion to the old age is greater than the remaining space size of the old age, and if it is greater, the full GC is changed directly. If it is less than, see if the Handlepromotionfailure setting allows the warranty to fail; if allowed, only minor GC will be performed, and if not allowed, a full GC should be performed instead.

The Cenozoic uses a replication collection algorithm, but for memory utilization, values use one of the survivor spaces as a rotational backup, so when a large number of objects survive after the minor GC (most extreme is that all objects in the Cenozoic are alive after the memory is reclaimed), the old age is required to make the allocation guarantee, Let the survivor not accommodate the object directly into the old age. Similar to the life of the loan guarantee, the old age to carry out such a guarantee, the premise is that the old age itself has to accommodate these objects of the remaining space, total number of objects will live, in the actual memory before the completion of the recovery is not clear, so had to take each of the previous recycling promotion to the old age object capacity average size value as experience , comparing with the rest of the old age, deciding whether to make full GC to make more space in the old age.

/**     * VM Args:-verbose:gc-xms20m-xmx20m-xmn10m-xx:survivorratio=8     *-xx:-handlepromotionfailure-xx:+ Printgcdetails     *    /public static void Testhandlepromotion () {        byte[] Allocation1,allocation2,allocation3 , Allocation4,allocation5,            allocation6,allocation7;        Allocation1 = new BYTE[2*_1MB];        Allocation2 = new BYTE[2*_1MB];        Allocation3 = new BYTE[2*_1MB];        Allocation1 = null;        Allocation4 = new BYTE[2*_1MB];        Allocation5 = new BYTE[2*_1MB];        Allocation6 = new BYTE[2*_1MB];        Allocation4 = null;        Allocation5 = null;        Allocation6 = null;        allocation7 = new BYTE[2*_1MB];    } 

Run results with Handlepromotionfailure=false:

[GC [Defnew:6651k->154k (9216K), 0.0033102 secs] 6651k->4250k (19456K), 0.0033813 secs] [times:user=0.00 sys=0.00, real=0.00 secs] [GC [Defnew:6384k->6384k (9216K), 0.0000288 secs][tenured:4096k->4250k (10240K), 0.0039019 secs] 10480k-> 4250K (19456K), [perm:2132k->2132k (12288K)], 0.0040460 secs] [times:user=0.00 sys=0.00, real=0.00 secs] Heap def NEW Generation Total 9216K, used 2211K [0x044e0000, 0x04ee0000, 0x04ee0000) Eden Space 8192K, 27% used [0x044e0000, 0x0470 8FE0, 0x04ce0000) from space 1024K, 0% used [0x04de0000, 0x04de0000, 0x04ee0000] to space 1024K, 0% used [0x04ce00  XX, 0x04ce0000, 0x04de0000) tenured generation total 10240K, used 4250K [0x04ee0000, 0x058e0000, 0x058e0000) the space 10240K, 41% used [0x04ee0000, 0x053068a8, 0x05306a00, 0x058e0000) compacting Perm gen Total 12288K, used 2137K [0x058e0 0x064e0000, 0x098e0000) The space 12288K, 17% used [0x058e0000, 0x05af6710, 0x05af6800, 0x064e0000) No gkfx Space S configured.

[GC [Defnew:6651k->154k (9216K), 0.0038289 secs] 6651k->4250k (19456K), 0.0038877 secs] [times:user=0.00 sys=0.00, real=0.00 secs] [GC [Defnew:6384k->154k (9216K), 0.0006008 secs] 10480k->4250k (19456K), 0.0006525 secs] [times:user=0.00 sys=0.00, real=0.00 secs] Heap def New Generation total   9216K, used 2366K [0x043d0000, 0x04dd0000, 0x04dd0000]  Eden space 8192K,  27% use d [0x043d0000, 0x045f8fe0, 0x04bd0000) from  space 1024K,  15% used [0x04bd0000, 0x04bf6888, 0x04cd0000]  to< C6/>space 1024K,   0% used [0x04cd0000, 0x04cd0000, 0x04dd0000) tenured generation total   10240K, used 4096K [0X04DD 0000, 0x057d0000, 0x057d0000) The   space 10240K,  40% used [0x04dd0000, 0x051d0020, 0x051d0200, 0x057d0000) Compacting Perm Gen Total  12288K, used 2137K [0x057d0000, 0x063d0000, 0x097d0000) The   space 12288K,  17% US Ed [0x057d0000, 0x059e6710, 0x059e6800, 0x063d0000) No GKFX spaces configured.

Memory allocation and reclamation policy