Repeated ParNews when Young Gen is Empty?

[Srinivas Ramakrishna]

On Mon, Jul 1, 2013 at 2:42 PM, Bernd Eckenfels
<bernd.eckenfels at googlemail.com> wrote:
> Am 01.07.2013, 22:44 Uhr, schrieb Andrew Colombi <acolombi at palantir.com>:
>> My question is, Why would it do three ParNews, only 300ms apart from
>> each other, when the young gen is essentially empty?  Here are three
>> hypotheses that I have:
>> * Is the application trying to allocate something giant, e.g. a 1
>> billion element double[]? Is there a way I can test for this, i.e. some
>> JVM level logging that would indicate very large objects being allocated.
>
> That was a suspicion of me as well. (And I dont know a good tool for Sun
> VM (with IBM you can trace it)).

I think it would be a good idea to dispay the requested size in jstat
logging along with GC cause. This will need both a jstat as well as a
JVM modificatio but would be worthwhile.

The JVM could also potentially display this in the verbose GC trace.
Don't know if that already is the case, but would definitely be
useful.

>
>> * Is there an explicit System.gc() in 3rd party code? (Our code is
>> clean.) We're going to disable explicit GC in our next maintenance
>> period.  But this theory doesn't explain concurrent mode failure.
>
> I think System.gc() will also not trigger 3 ParNew in a row.
>
>> * Maybe a third explanation is fragmentation? Is ParNew compacted on
>> every collection?  I've read that CMS tenured gen can suffer from
>> fragmentation.
>
> ParNew is a copy collector, this is automatically compacting. But the
> promoted objects might of course fragment due to the PLABs in old. Your
> log is from 13h uptime, do you see it before/after as well?
>
> Because there was no follow up, I will just mention some more candidates
> to look out for, the changes around CMSWaitDuration (RFE 7189971) I think
> they have been merged to 1.7.0.
>
> And maybe enabling more diagnostics can help:
>
> -XX:PrintFLSStatistics=2


Aside: of course, fragmentation in the old gen can cause concurrent
mode failure or very slow minor gc's, but they shouldn't lead to 3
back-to-back minor gc's in quick succession.

My favourite theory for the 3 back-to-back minor gc's is still that
it's a case of allocating large objects in quick succession. Perhaps
it'll show that the policy for allocating large objects might be a bit
better than is the case currently (just an off-hand thought; i have no
specific ideas or suspicions).

-- ramki

>
> Greetings
> Bernd
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use