does CMS collector ever compact?

[Y Srinivas Ramakrishna]

Hi Shane --

> 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?

<Jon already answered yr question.>

It is interesting that the onset of each subsequent promotion failure 
happens at a lower occupancy than the previous. I do not believe I have
seen that behaviour before, and do not have any conjectures as to why
that could be happening. Indeed I would normally have expected it to
be larger (higher occupancy) after the first and then to remain stable
at that value thereafter. Perhaps you can share some gc logs showing this,
if possible? (email the logs offline to one of us, if so.) Sometimes,
looking at entire gc logs as a whole fires the right cerebral neurons.

We are actively working on improving some of our heuristics
related to controlling fragmentation (under CR 6631166); stay tuned
for some improvements in that area soon.

-- ramki 

> 
> 
> 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
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use