One more...

[Srinivas Ramakrishna]

There's apparently plenty of room in the old gen, and it seems that Eden
was probably not full either (although that was not clear from this lone
snippet).
Sometimes a scavenge and a full gc will be done to accomodate a large
allocation request. It's difficult top tell here (because the :cause" is
not printed --
but probably should be for this kind of post-facto analysis?)

A larger log might allow one to make better guesses (but probably still
guesses) as to what might have caused this full gc.

-- ramki


On Fri, Nov 16, 2012 at 1:02 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:

> 562248.437: [GC 562248.437: [ParNew
> Desired survivor size 25067520 bytes, new threshold 1 (max 4)
> - age   1:   30984912 bytes,   30984912 total
> - age   2:      81008 bytes,   31065920 total
> - age   3:     336544 bytes,   31402464 total
> - age   4:   11779200 bytes,   43181664 total
> : 200450K->48960K(440896K), 0.0550990 secs]562248.493: [CMS:
> 25479885K->12417662K(60327552K), 41.9279830 secs]
> 25680117K->12417662K(60768448K), [CMS Perm : 161138K->157115K(262144K)],
> 41.9835910 secs]
>
> But the VM isn't in a CMS cycle! Is this a mislabeled concurrent mode
> failure?????
>
> Regards,
> Kirk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121219/89412b0e/attachment.htm>