does CMS collector ever compact?

[Tony Printezis]

(this is a wild shot in the dark!)

Does the application have an array-based data structure (ArrayList, 
HashMap, etc.) that keeps growing? Usually such data structures double 
the size of the associated array every time they need to grow it. The 
larger the array is, the earlier (maybe!) it will cause fragmentation.

Tony

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

-- 
----------------------------------------------------------------------
| Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
|                                   | MS BUR02-311                   |
| e-mail: tony.printezis at sun.com    | 35 Network Drive               |
| office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
----------------------------------------------------------------------
e-mail client: Thunderbird (Solaris)