Detailed Memory allocation analysis

Just look at the code.

Package jvm.part_3;/** * VM parameters:-verbose:gc-xms20m-xmx20m-xmn10m-xx:+printgcdetails  *-xx:survivorratio=8 * @autho R Foolishbird_lmy * */public class Testeden {private static final int _1mb = 1024*1024;public static void Main (string[] Ar GS) {byte[] a1,a2,a3,a4;a1 = new BYTE[2*_1MB];A2 = new Byte[2*_1mb];a3 = new BYTE[2*_1MB];A4 = new BYTE[4*_1MB];}}

First look at the settings of the virtual machine parameters:-xms20m-xmx20m for the size of the Java heap is set to 20MB is not extensible,-XMN10M representative assigned to the Cenozoic region 10MB, the remaining 10MB is the old age region;-xx:+printgcdetails is to tell the virtual machine to recycle the print memory when garbage collection occurs, and to output the current memory area allocations when the process exits; -xx:survivorratio=8 This is a virtual machine parameter, set the new generation of Eden and survivor area of the space ratio of 8:1; Previously, the replication algorithm for garbage collection was to divide the heap memory into an Eden area and two surivor zones. Allocating memory is first allocated to the Eden and S area, where a piece of S-zone is retained, when the garbage collection, the E and the S area of the surviving objects are copied to the reserved s area, and then collected uniformly, the advantage is that the recovered memory is not fragmented;

However, one problem is that if the amount of memory to be recycled is very large, but the reserved s area is out of memory space, this involves the issue of assigning a security, which is followed by the actual code to analyze the problem;

The following is a direct view of the code running log:

　　

[Gc[defnew:6800k->454k (9216K), 0.0043097 secs] 6800k->6598k (19456K), 0.0043602
secs] [times:user=0.00 sys=0.00, real=0.01 secs]
Heap
def New Generation Total 9216K, used 5042K [0x03940000, 0x04340000, 0x0434000
0)
Eden Space 8192K, 56% used [0x03940000, 0x03dbaf78, 0x04140000)
From space 1024K, 44% used [0x04240000, 0X042B19A8, 0x04340000)
To space 1024K, 0% used [0x04140000, 0x04140000, 0x04240000)
Tenured generation total 10240K, used 6144K [0x04340000, 0x04d40000, 0x04d400
00)
The space 10240K, 60% used [0x04340000, 0x04940030, 0x04940200, 0x04d40000)
Compacting Perm Gen Total 12288K, used 1601K [0x04d40000, 0x05940000, 0x08d400
00)
The space 12288K, 13% used [0x04d40000, 0x04ed0440, 0x04ed0600, 0x05940000)
No shared spaces configured.

Analyze Memory logs:

6800k->454k (9216K) 9216K represents the total capacity of the current memory area, the current memory area is an E and a s, the other S region is reserved, just now we have set the total Cenozoic memory capacity of 10mb,e:s=8:1, so the total capacity should be 9M = 9216K;

Continuing analysis, the first three array objects each allocate 2MB of memory space, a total of 6mb=6144k this is not a problem, because the space of e is enough to allocate 8MB. And 6800k->454k This 6800K is the memory usage in this area, contains 3 objects of 6144K space, and the extra 656K estimate is the other virtual runtime comes with the occupation. After the arrival of the 4th array object, the object size is 4MB, first to the new generation of e-zone, it is obvious that there is not enough memory allocated to it at this time, the minor GC is the new generation of garbage collection, and this is going to be the replication algorithm we said before, The virtual machine first copies the surviving objects in E and S to the reserved piece of S, and then recycles it uniformly. Trouble has come, the trouble is now the memory area of the s only 1MB, unable to store these objects, this time can only be assigned to guarantee mechanism, directly at once these surviving objects to the old age to save.

The allocation guarantee mechanism is like a protection mechanism, because the new generation of object 98% is to die, the object of death recovery is very frequent, so there are very few objects to survive the need to replicate to the S region, once this happens, the virtual machine can make a guarantee for our object, These big objects are definitely good objects, not the problem, not to go to prison in s to wait, go straight to the old age pension bar, if there is nothing to call it to play it warm up, then you can go to die the fate of being recycled.

Well, continue to 6MB of the large object has been directly dropped into the old age, tenured generation total 10240K, used 6144K of the old years altogether 10MB, is now used to 6MB, exactly the same. Then you can be in the new generation of object recycling, OK, you all can go to die, click below, instantly 6800k->454k into 454K, it is obviously recycled. Look at this 6800k->6598k (19456K), a look at the wrong ah, recycling completely did not reduce, see clearly, this 19456=19mb refers to the whole heap memory size, why is this 19MB? The new Generation E is 8MB, two S is 2MB, the old age assigned 10MB, can only explain that the reserved s area is not counted!!

Keep looking at this 6800k->6598k (19456K), because 3 array objects directly from the e-Cenozoic dropped to the old age, resulting in total heap memory or unchanged, garbage collection basically no recycling objects, the equivalent of the white sweep, the small partner just threw rubbish from the room to the balcony hidden up, The house tube is not checked, but the rubbish is still in the dormitory, then the egg!

OK, now the E-zone has been emptied, 8MB of memory, installed your ya 4MB little more than enough, come in!!

There are some analysis to make up later ... Cond

Detailed Memory allocation analysis