Why is there no FullGC, but the old gene from 99% to 14% shows up in jstat-gcutil results?
jstat -gcutil as shown below:
The old gene is first from 13.78 to 99.98, then to 14.81, but FGCT is always 1, Why?
In addition to FullGC, are there other reasons for this situation?
GC are CMS and JVM options:
-Xms4096m -Xmx4096m -Xss256k -XX: PermSize = 256m -XX: MaxPermSize = 256m -XX: NewSize = 512m -XX: MaxNewSize = 512m -XX: SurvivorRatio = 16 -XX: + UseParNewGC -XXThreads: Parallel 16 MaxTenuringThreshold = 32 -XX: + UseConcMarkSweepGC -XX: ParallelCMSThreads = 8 -XX: + CMSParallelRemarkEnabled -XX: + CMSPermGenPrecleaningEnabled -XX: CMSInitiatingOccupancyFraction = 70 -XX: +
source to share
-
Full GC HotSpot GC is calculated when young generation and persistent generation are collected ... (Source: Performance Impact Analysis on Memory Usage and Garbage Collection , Major Partitions and Small Garbage Collections)
-
There is an ambiguous use of the term "full garbage collection" in different tools , some do not show any GC events, while others report gc events if they run at the same time and the same JVM. Keep this in mind if you need to compare outputs / reports.
So back to your question:
When I look at your output, I can see that the use of constant space is increasing. It started at 19.59 and is 19.70 on the last line of your issue. Up to this point, there was no timekeeping with a constant generator . It is for this reason that the FGC is still 1.
Additional notes regarding jstats -gcutil output.
- O: using old space or as you call it old gen.
- P: using constant space
- YGC: the amount of garbage collection of the younger generation
- FGC: full garbage collection
- GCT: total garbage collection time.
. S0 S1 E O P YGC YGCT FGC FGCT GCT
12.44 0.00 27.20 9.49 96.70 78 0.176 5 0.495 0.672
12.44 0.00 62.16 9.49 96.70 78 0.176 5 0.495 0.672
12.44 0.00 83.97 9.49 96.70 78 0.176 5 0.495 0.672
0.00 7.74 0.00 9.51 96.70 79 0.177 5 0.495 0.673
The values shown for YGC, YGCT, FGC, and FGCT are from when the Hotspot JVM was started and when you ran jstat -gcutil. Just a case where you are wondering, the exit might start, for example. 12 FSK in the first line.
Here is the jstat doc: Java 6 jstat doc
source to share
I've done some tests myself and my conclusion is that it looks like it is a bug in jstat when working with your JVM options. I ran jstat -gc and jstat -gcutil at the same time in a simple test application and I had the following output:
jstat -gc:
S0C S1C S0U S1U EC EU OC OU
29120,0 29120,0 0,0 0,0 466048,0 18642,2 3670016,0 0,0
29120,0 29120,0 0,0 0,0 466048,0 18642,2 3670016,0 0,0
29120,0 29120,0 0,0 0,0 466048,0 18642,2 3670016,0 0,0
29120,0 29120,0 0,0 0,0 466048,0 18642,2 3670016,0 0,0
29120,0 29120,0 0,0 0,0 466048,0 18642,2 3670016,0 0,0
29120,0 29120,0 0,0 0,0 466048,0 55926,2 3670016,0 0,0
29120,0 29120,0 0,0 0,0 466048,0 369663,6 3670016,0 0,0
29120,0 29120,0 0,0 29120,0 466048,0 466048,0 3670016,0 94773,6
29120,0 29120,0 0,0 29120,0 466048,0 299100,8 3670016,0 118478,6
29120,0 29120,0 29120,0 0,0 466048,0 9163,2 3670016,0 254498,6
jstat -gcutil
S0 S1 E O P YGC YGCT FGC FGCT GCT
0,00 0,00 4,00 0,00 0,93 0 0,000 0 0,000 0,000
0,00 0,00 4,00 0,00 0,93 0 0,000 0 0,000 0,000
0,00 0,00 4,00 0,00 0,93 0 0,000 0 0,000 0,000
0,00 0,00 4,00 0,00 0,93 0 0,000 0 0,000 0,000
0,00 0,00 4,00 0,00 0,93 0 0,000 0 0,000 0,000
0,00 0,00 26,00 0,00 0,97 0 0,000 0 0,000 0,000
0,00 0,00 89,32 0,00 0,97 0 0,000 0 0,000 0,000
0,00 100,00 100,00 100,00 0,97 1 0,000 0 0,000 0,000
0,00 100,00 80,02 3,23 0,97 1 0,905 0 0,000 0,905
100,00 0,00 13,76 6,93 0,97 2 1,441 0 0,000 1,441
As you can see, my old one used when running -gcutil jumps to 100, even if the application is just starting to populate the old gene. jstat -gc shows that the old generation is almost completely empty. The app is very simple and just populates the HashMap, so there is no way for the old gene to be 100% full when jstat-gcutil says so.
source to share