One more...

Srinivas Ramakrishna ysr1729 at gmail.com
Wed Dec 19 12:17:00 PST 2012


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: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20121219/89412b0e/attachment.html 


More information about the hotspot-gc-dev mailing list