Java Virtual Machine 7: Memory allocation principle

Http://www.cnblogs.com/xrq730/p/4841177.html

Objective

The memory allocation of objects, in large directions, is allocated on the heap, in a few cases may also be directly allocated in the old age, the allocation of rules is not completely fixed, the details of which depends on what kind of garbage collector combination is currently used, of course, there are memory-related parameters in the virtual machine. The garbage collector combination is typically serial+serial old and parallel+serial old, which is the default garbage collector combination in client mode, which is the default garbage collector combination in server mode. This article uses the contrast learning method to compare the same object assignment principle in client mode and server mode.

Tlab

First talk about what is Tlab. Memory allocation actions can be performed in different spaces by thread, i.e. each thread pre-allocates a small chunk of memory in the Java heap, called the local thread allocation buffer (thread local Allocation buffer,tlab). Which thread needs to allocate memory, on which thread the Tlab is allocated. If the virtual machine uses Tlab, it can be set by the-xx:+/-usetlab parameter. One of the purposes of this is to ensure thread safety for creating objects when creating an object concurrently. Tlab is small, the way to allocate memory directly on the Tlab is called fast allocation, and the Tlab size is not enough, so memory allocation in the Eden area is called a slow allocation method.

Object priority assignment on Eden area

It says that different garbage collector combinations have an impact on memory allocation rules, see where the impact is and explain why, the virtual machine parameter is "-VERBOSE:GC-XX:+PRINTGCDETAILS-XMS20M-XMX20M-XMN10M-XX: Survivorratio=8 ", 10M Cenozoic, 10M old age, 10M Cenozoic 8M of Eden District, two survivor District each 1 m. The code is all in the same paragraph

PublicClassedenallocationtest{PrivateStaticFinalint _1MB = 1024 * 1024public static void< Span style= "color: #000000;" > main (string[] args) {byte[] Allocation1 = new byte[2 * _1MB]; byte[] Allocation2 = new byte[2 * _1MB]; byte[] Allocation3 = new byte[2 * _1MB]; byte[] Allocation4 = new byte[4 * _1MB];}       

In the client mode

[GC [Defnew:6487k->194k (9216K), 0.0042856 secs] 6487k->6338k (19456K), 0.0043281 secs] [times:user=0.00 sys=0.00, real=0.00secs] Heap defNew Generation total 9216K, used 4454K [0x0000000005180000, 0x0000000005b80000, 0x0000000005b80000Eden Space 8192K, 52% used [0x0000000005180000, 0x00000000055a9018, 0x0000000005980000) tenured generation total 10240K, used 6144K [0x0000000005b80000, 0x0000000006580000, 0x0000000006580000) The space 10240K, 60% used [0x0000000005b80000, 0x0000000006180048, 0x0000000006180200, 0x0000000006580000) compacting Perm Gen Total 21248K, used 2982K [0x0000000006580000, 0x0000000007a40000, 0x000000000b980000) The space 21248K, 14% used [0x0000000006580000, 0x0000000006869890, 0x0000000006869a00, 0x0000000007a40000) No GKFX spaces configured.       

Server mode

Heap Psyounggen Total 9216K, used 6651K [0x000000000af20000, 0x000000000b920000, 0x000000000b920000) to space 1024K, 0% used [0x000000000b720000,0x000000000b720000,0x000000000b820000) object space 10240K, 40% used [0x000000000a520000,0x000000000a920018,0x000000000af20000 ) Pspermgen total 21248K, used 2972K [0x0000000005120000, 0x00000000065e0000, 0x000000000a520000) object space 21248K, 13% used [0x0000000005120000, 0x0000000005407388,0x00000000065e0000)       

See in the client mode, the last allocation of 4M in the Cenozoic, the first allocation of 6M in the old age; In server mode, the last allocated 4M in the old age, the first allocation of 6M in the Cenozoic . Demonstrates that different garbage collector combinations have an impact on the allocation of objects. Tell the difference between the two reasons:

1, the client mode, the new generation allocated 6M, the virtual machine in front of the GC 6487K, more than 6M is 6144K, mostly because Tlab and edenallocationtest this object occupied space, Tlab can through the "-xx:+printtlab" This virtual machine parameter to view the size. ok,6m more, and then came a 4M, eden+ a survivor a total of 9M is not enough to allocate, this time will trigger a minor GC. But triggering minor GC also useless, because Allocation1, Allocation2, Allocation3 Three references also exist, another 1M of survivor is not enough to put down the 6 m, then this time minor The effect of GC is actually to transfer the 6 m content into the old age by assigning a guarantee mechanism. Then a 4M, because at this time minor GC after the Cenozoic only left 194K, enough to allocate, so 4M smoothly into the new generation.

2, the server mode, the front is the same, but in the GC when there is a little difference. The GC will also be judged once, if the allocated memory is half the size of the >=eden area, then the memory allocated will be placed in the old age. To allocate the 4m,eden area 8M, just half, and the old age 10M, enough to allocate, so 4M directly into the old age. To verify the conclusion, we changed the 4M distribution of 3 2M to 3M.

PublicClassedenallocationtest{PrivateStaticFinalint _1MB = 1024 * 1024public static void< Span style= "color: #000000;" > main (string[] args) {byte[] Allocation1 = new byte[2 * _1MB]; byte[] Allocation2 = new byte[2 * _1MB]; byte[] Allocation3 = new byte[2 * _1MB]; byte[] Allocation4 = new byte[3 * _1MB];}       

Run the result as

[GC [Psyounggen:6487k->352k (9216K)] 6487k->6496k (19456K), 0.0035661 secs] [times:user=0.00 sys=0.00, real=0.00secs] [Full GC [psyounggen:352k->0k (9216K)] [psoldgen:6144k->6338k (10240K)] 6496k->6338k (19456K) [Pspermgen : 2941k->2941k (21248K)], 0.0035258 secs] [times:user=0.02 sys=0.00, real=0.00secs] Heap Psyounggen total 9216K, used 3236K [0x000000000af40000, 0x000000000b940000, 0x000000000b940000) Eden Space 8192K, 39% used [0x000000000af40000,0x000000000b269018,0x000000000b740000) from space 1024K, 0% use d [0x000000000b740000,0x000000000b740000,0x000000000b840000) to space 1024K, 0% used [0x000000000b840000, 0x000000000b840000,0x000000000b940000) Psoldgen total 10240K, used 6338K [0x000000000a540000, 0x000000000af40000, 0x000000000af40000) object Space 10240K, 61% used [0x000000000a540000,0x000000000ab70858,0x000000000af40000] Pspermgen total 21248K, used 2982K [0x0000000005140000, 0x0000000006600000, 0x000000000a540000) object Space 21248K, 14% used [0x0000000005140000,0x0000000005429890,0x0000000006600000)      

See 3M in the Cenozoic, 6M through the allocation of security mechanism into the old age.

Large objects go straight into the old age

The virtual machine parameter is "-xx:+printgcdetails-xms20m-xmx20m-xmn10m-xx:survivorratio=8-xx:pretenuresizethreshold=3145728", The last parameter indicates that an object larger than this setting is allocated directly in the old age, and this is done to avoid a large amount of memory duplication between the Eden Zone and the two survivor zones. The test code is

Class oldtest{    int _1mb = 1024x768 * 1024x768voidbyte[4 * _1MB];}}    

In the client mode

Heap defNew Generation total 9216K, used 507K [0x0000000005140000, 0x0000000005b40000, 0x0000000005b40000Eden Space 8192K, 6% used [0x0000000005140000, 0x00000000051bef28, 0x0000000005940000) from space 1024K, 0% used [0x0000000005940000, 0x0000000005940000, 0x0000000005a40000] to space 1024K, 0 % used [0x0000000005a40000, 0x0000000005a40000, 0x0000000005b40000) tenured generation total 10240K, used 4096K [0x00 00000005b40000, 0x0000000006540000, 0x0000000006540000) The space 10240K, 40% used [0x0000000005b40000, 0x0000000005f40018, 0x0000000005f40200, 0x0000000006540000) compacting Perm gen Total 21248K, used 2972K [ 0x0000000006540000, 0x0000000007a00000, 0x000000000b940000) The space 21248K, 13% used [0x0000000006540000, 0x00000000068272a0, 0x0000000006827400, 0x0000000007a00000) No GKFX spaces configured.      

Server mode

Heap Psyounggen Total 9216K, used 4603K [0x000000000afc0000, 0x000000000b9c0000, 0x000000000b9c0000) to space 1024K, 0% used [0x000000000b7c0000,0x000000000b7c0000,0x000000000b8c0000) object space 10240K, 0% used [0x000000000a5c0000,0x000000000a5c0000,0x000000000afc0000 ) Pspermgen total 21248K, used 2972K [0x00000000051c0000, 0x0000000006680000, 0x000000000a5c0000) object space 21248K, 13% used [0x00000000051c0000, 0x00000000054a72a0,0x0000000006680000)       

See the client mode 4M directly into the old age, server mode 4M is still in the Cenozoic . The reason for this difference is that the "-xx:pretenuresizethreshold" parameter is valid for the serial+serial old garbage collector combination and is not valid for the parallel+serial old garbage collector combination .

Several other principles

The principles listed above are not important, just demos, and do not need to be remembered, because the actual process we may use is not a combination of the above garbage collector, may use the parnew garbage collector, may use the G1 garbage collector. There are many scenarios, and it is important to have a way to know what the garbage collector is using for object assignment when it is actually used, because understanding these principles is the first step in tuning. Here are two additional principles for object assignment:

1, long-term survival of the object will enter the old age. Objects in the Eden area are not recycled after a minor GC, the object ages +1, and when the object age reaches the value of "-xx:maxtenuringthreshold", the object is promoted to the old age.

2. The sum of all objects of the same age in Survivor space is greater than half of the survivor space, and objects older than or equal to that age can enter the old age without waiting for the age of "-xx:maxtenuringthreshold" setting requirements

Java Virtual Machine 7: Memory allocation principle