John,
Can you run with an early access jdk8? If so then enable the flag PrintGCCause and you should get the reasons for these GCs. What I have right now is just a GC log. But I'll try to get the data for JDK8 build.
How do the timestamps of these premature GCs compare to the previous GC? Are they back to back with a non-premature GC? It starts right after the previous GC (see attached excerpt from the GC log). Normally, minor GCs are scheduled every 5 secs.
Does it look like the application
didn't run between a normal GC and the premature GC? You can use PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime to see how long the application runs between safepoints. It may be the case (at least it seems so - there's no output from application in between). Thanks for the suggestion. I'll try to experiment with these flags.
These premature GCs could be GC locker related. When the last thread exits a critical region there is a slight window before the GC locker initiated GC where another application can nip in and successfully schedule a regular GC. Can you elaborate on this a little? I don't grasp how it can lead to a premature GC. Don't we schedule a GC anyway? Or does GC locker initiated GC have some special treatment?
Best regards, Vladimir Ivanov
JohnC
On 5/15/2013 8:05 AM, Vladimir Ivanov wrote:
Hi,
I see minor GCs occurring when young gen occupancy is very low, e.g.: [ParNew: 8446K->7381K(943744K), 0.0274200 secs]
Does anybody know what provokes such "premature" GCs?
There's no CMS concurrent cycle running or any other interesting GC events occurred around that moment - just a sequence of minor GCs with such outlier.
Such premature minor GCs occur on a regular basis.
JDK version: 6u37, 64-Bit Server VM (20.12-b01, mixed mode)
Best regards, Vladimir Ivanov