CMS collection keep working during holiday

[Y Srinivas Ramakrishna]

As the old saying goes, a picture (attached, courtesy of gchisto)
is worth a thousand words (well, actually only about 190 words below,
but still). See how the scavenge times become so much better
following the full gc's? (For some reason gchisto and our
log fixer are unable to fix up and recognise the most dramatic
one far to the right at timestamp 504379.249.

> It so happens that in some cases you can actually clearly see the
> deleterious effect of accumulating perm gen garbage on the performance
> of not only CMS (which, as in your case, had an artifically bloated
> footprint and was running useless cycles), but on scavenges --
> the latter is two-fold: firstly the quasi-immortal (modulo
> mark-compact which reclaims them) class loaders and other class-cohorts
> act as barriers to coalition and tend to fragment the old gen, causing
> much pain to scavenges, which slow down over time; further,
> the dead classes in the perm gen act as "dead roots" that inflates
> the root-scanning time for scavenges and further slows down scavenges.
> In a recent exchange, i think on this list, we saw a nice expample
> of that. We can probably extract a time-series plot of the scavenge
> times from your logs to see if we see a similar trending which
> is often a signature of problems such as these. (Of course similar
> signatures would appear also with some memory leaks, as Tony and Kirk
> suspected earlier.)

-- ramki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timeseries_gc.png
Type: image/png
Size: 27329 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20081010/e6c00a9b/timeseries_gc.png>