Source: Concurrent Programming Network
link: http: //ifeve.com/ depth understanding G1 garbage collector /
G1 GC is one of the new features Jdk7 of, Jdk7 + version can be self-configured G1 as the JVM GC option; as JVM GC algorithm of a major upgrade, after DK7u G1 has been relatively stable, and future plans to replace CMS, it is necessary to understand the next :
Unlike other generational collection algorithm, G1 will heap space being divided into separate blocks independent of one another. Each region may belong to both the O region, there may be a region Y, and each type of space region may be discontinuous (CMS comparative O, and Y region area must be continuous). This will O area is divided into a plurality of blocks from the idea: When a background thread concurrency looking for recyclable objects, some blocks contain recyclable objects a lot more than other blocks. While cleaning up the blocks G1 still need to suspend application threads, but you can use relatively little recovery time priority contain up to block spam. This is why the reasons for the G1 Garbage First name: the first time to deal with the most garbage blocks.
Usually work in most systems use CMS, even a silent upgrade to JDK7 default still use CMS, then the G1 relative to the difference in the CMS:
- G1 has an advantage in terms of compression space
- G1 memory space is divided into regions by (Region) way to avoid memory fragmentation issues
- Eden, Survivor, Old area is no longer fixed, more flexible and efficient use of memory on it
- G1 garbage collection time can be controlled to avoid application of the avalanche phenomenon by setting the expected pause time (Pause Time)
- G1 immediately after the recovery of memory free memory consolidation while doing work, and the default CMS is doing STW (stop the world) when
- G1 will be used in Young GC, whereas CMS can only be used in the O Zone
For now, CMS GC policy choice or default, G1 may be more suitable in the following scenarios:
- Server multicore CPU, JVM memory footprint larger applications (at least greater than 4G)
- It will generate a large amount of memory fragmentation during operation, requiring constant compression space
- Want more controllable, predictable GC pause period; prevent high concurrent applications under avalanche
A complete G1GC detailed process:
G1 during operation mainly includes the following four operating modes:
- YGC (Unlike CMS)
- Concurrent stage
- Mixed Mode
- full GC (G1 usually occurs when there is a problem)
CVL:
The following is a memory area is a schematic front YGC:
A different region (Region) Each figure represents the G1 cell block, the block inside the letters represent generational memory types (e.g., [E] Eden, [O] Old, [S] Survivor) blank blocks does not belong to any partition; Gl can be specified in this area belong to a class of Eden or O when needed area.
G1 YoungGC when Eden full of trigger, after the recovery of all the blocks belonging to Eden before the whole blank. Then there belongs at least one block (FIG area that is half full) S region, while there may be some moved O data area.
Most of the current application system using scouring PrintGCDetails GC parameters play log, this parameter is also effective for G1, but quite different from the log contents; Here is an example of a Young GC:
23.430: [GC pause (young), 0.23094400 secs]
...
[Eden: 1286M(1286M)->0B(1212M)
Survivors: 78M->152M Heap: 1454M(4096M)->242M(4096M)]
[Times: user=0.85 sys=0.05, real=0.23 secs]
The above contents of the log analysis: Young GC actually occupied 230 ms, 850 ms wherein GC thread occupies CPU time
E: from 1286MB memory footprint becomes 0, have been removed
S: increased from 78M to 152M, instructions shift from Eden over 74M
Heap: occupation from 1454 became 242M, explained the Young GC total memory space freed 1212M
In many cases, the object will be part of the S region was promoted to the Old District, another area if S is full, Eden surviving objects are promoted directly to the Old District, Old In this case the space will rise
Concurrent stages:
Before and after a recovery period of concurrent memory usage G1 as shown below:
From the above table you can see the following:
1, Young Zone has changed, which means that there was a YGC (CMS this point and there is difference) at least in the G1 phase concurrent, Eden has been completely emptied before the tag, because while working at the application stage concurrent threads, so you can see there are new occupation Eden
2, some regions are labeled X, these areas belong to the O area, at this time there are still data storage, except that G1 has marked most of these areas include garbage, which is the region's highest revenue recovery
3, after the completion of the concurrent stages actually becomes larger capacity region of O (O + X box). This is because the process occurs in the YGC new object enters due. In addition, at this stage there is no recovery of any object in the O zone: its main function is to mark up the garbage block out. Objects are actually really began at a later stage is recovered
G1 concurrent marking cycle can be divided into several stages, some of which need to suspend the application thread. The first stage is the initial marking phase. This phase will suspend all application threads - Part of the reason is that this process will be executed once YGC, the following is a log example:
50.541: [GC pause (young) (initial-mark), 0.27767100 secs]
[Eden: 1220M(1220M)->0B(1220M)
Survivors: 144M->144M Heap: 3242M(4096M)->2093M(4096M)]
[Times: user=1.02 sys=0.04, real=0.28 secs]
The above shows that the log occurred YGC, suspended for this application threads 280 milliseconds, Eden area is cleared (71MB Young moved from the area O area).
Log words inside initial-mark indicates that the background of the concurrent GC phase began. Because the initial stage itself is marked to suspend application of the thread,
G1 just in the process of YGC's put this thing done together. For this purpose to bring additional overhead is not large, an increase of 20% CPU, slightly longer pause time some appropriate.
Next, the scan start Gl root zone, log example:
50.819: [GC concurrent-root-region-scan-start]
51.408: [GC concurrent-root-region-scan-end, 0.5890230]
Spent a total of 580 milliseconds, this process does not suspend the application threads; a background thread parallel processing. This stage can not be interrupted by YGC, and therefore have sufficient background thread CPU time is critical. If the Young area space just when scanning Root
Can be performed after full, YGC must wait root scan. Impact is YGC pause time will be increased. This time, GC log is this:
350.994: [GC pause (young)
351.093: [GC concurrent-root-region-scan-end, 0.6100090]
351.093: [GC concurrent-mark-start],0.37559600 secs]
GC pauses can be seen here took place before the root end of the scan, indicating YGC occurred waiting, waiting time is about 100 milliseconds.
After the root scan is complete, G1 entered a concurrent marking phase. This is exactly the background of the stage; GC logs inside the following information represents the beginning and end of this phase:
111.382: [GC concurrent-mark-start]
....
120.905: [GC concurrent-mark-end, 9.5225160 sec]
Concurrent mark phase can be interrupted, for example, the process will take place the YGC. After this stage there will be a second stage marked and cleanup stages:
120.910: [GC remark 120.959:
[GC ref-PRC, 0.0000890 secs], 0.0718990 secs]
[Times: user=0.23 sys=0.01, real=0.08 secs]
120.985: [GC cleanup 3510M->3434M(4096M), 0.0111040 secs]
[Times: user=0.04 sys=0.00, real=0.01 secs]
These two stages will suspend application of the same thread, but time is short. Then there is the extra time to clean up the concurrent stages:
120.996: [GC concurrent-cleanup-start]
120.996: [GC concurrent-cleanup-end, 0.0004520]
So far, a normal G1 cycle has been completed - this period is mainly to do is to discover which areas contain the most recyclable garbage (marked X), the actual release less space.
Mixed GC:
Next G1 perform a series of mixed GC. This period will be as clean and above YGC marked area X at the same time, the so called mixing phase, the following is a schematic longitudinal GC performing mixing:
Like ordinary YGC as, G1 completely emptied out while adjusting the survivor Eden area. In addition, the two markers was also recovered, they have a common characteristic is the object that contains the most recyclable, it is absolutely part of the space these two regions have been released. Any surviving target these two areas have been moved to other areas (and YGC live objects promoted to O area similar). This is why the G1 CMS heap memory fragmentation less than a lot of reasons - while moving these objects is in the compression memory. The following is a mixed GC log:
79.826: [GC pause (mixed), 0.26161600 secs]
....
[Eden: 1222M(1222M)->0B(1220M)
Survivors: 142M->144M Heap: 3200M(4096M)->1964M(4096M)]
[Times: user=1.01 sys=0.00, real=0.26 secs]
Logs can be noted that the above Eden released 1222MB, but the release of the entire heap memory space is greater than this number. Difference between the number seems relatively small, only 16MB, but also have to consider the subject area of survivor promoted to O area; in addition, each time just to clean up the mixed GC O memory area part of the entire GC will continue until almost all of the marked area garbage objects were recovered after the stage finished G1 will return to normal YGC stage. Periodic, when the O memory area occupied by a certain number of G1 will open a new phase of parallel GC.