does CMS collector ever compact?

[Shane Cox]

Periodically our application encounters promotion failures when running the
CMS collector, presumably due to a fragmented Tenured space.  Once the first
failure occurs, we tend to see subsequent failures at lower occupancies of
Tenured space.  For example, the first promotion failure might occur when
Tenured is 70% full, the next 68%, then 65%, ... you get the picture.  So my
question is whether a compaction will ever be performed to resolve the
fragmentation?


I'm not a programmer, but I see comments in
concurrentMarkSweepGeneration.cpp that lead me to believe that a compact
would happen if UseCMSCompactAtFullCollection is set to TRUE and the
threshold set by CMSFullGCsBeforeCompaction has been exceeded.  However,
since the defaults are TRUE and 0 respectively, I would think that the first
Full GC triggered by a promotion failure would perform a compact.
Apparently I'm missing something.

Commets from concurrentMarkSweepGeneration.cpp
  // Normally, we'll compact only if the UseCMSCompactAtFullCollection
  // flag is set, and we have either requested a System.gc() or
  // the number of full gc's since the last concurrent cycle
  // has exceeded the threshold set by CMSFullGCsBeforeCompaction,
  // or if an incremental collection has failed


Any clarification in this matter would be appreciated.

FYI, normally we are able to avoid promotion failures by setting
CMSOccupancyFraction to an aggressive number such as 50, though this comes
at the cost of a much larger heap and slower minor collections.

Thanks,
Shane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20081024/d55eda57/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use