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).<br>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 --<br>
but probably should be for this kind of post-facto analysis?)<br><br>A larger log might allow one to make better guesses (but probably still guesses) as to what might have caused this full gc.<br><br>-- ramki<br><br><br><div class="gmail_quote">
On Fri, Nov 16, 2012 at 1:02 AM, Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk@kodewerk.com" target="_blank">kirk@kodewerk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
562248.437: [GC 562248.437: [ParNew<br>
Desired survivor size 25067520 bytes, new threshold 1 (max 4)<br>
- age   1:   30984912 bytes,   30984912 total<br>
- age   2:      81008 bytes,   31065920 total<br>
- age   3:     336544 bytes,   31402464 total<br>
- age   4:   11779200 bytes,   43181664 total<br>
: 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]<br>
<br>
But the VM isn't in a CMS cycle! Is this a mislabeled concurrent mode failure?????<br>
<br>
Regards,<br>
Kirk<br>
<br>
</blockquote></div><br>