RFR (S): 7066063: CMS: "Conservation Principle" assert failed

Bengt Rutisson bengt.rutisson at oracle.com
Mon May 20 20:43:16 UTC 2013


Hi everyone,

Could I have a couple of reviews for this small change?
http://cr.openjdk.java.net/~brutisso/7066063/webrev.00/

Background :

We hit this assert in the allocation statistics for CMS:

assert(prevSweep() + splitBirths() + coalBirths() >= splitDeaths() + 
coalDeaths() + (ssize_t)count) failed: Conservation Principle

The problem is in CompactibleFreeListSpace::reset(). That method calls 
FreeList<Chunk>::return_chunk_at_head(), which calls increment_count().

All other call sites that increment the count also updates either the 
split birth or coal birth statistics, but 
CompactibleFreeListSpace::reset() does not do that.

My reproducer hits the assert every time I run it. If I add a call to 
coalBirth() in CompactibleFreeListSpace::reset() it never hits the assert.

Here are the other calls to return_chunk_at_head and how they update the 
statistics:

CompactibleFreeListSpace:: par_get_chunk_of_blocks()
  -> calls set_split_births()

CompactibleFreeListSpace::returnChunkToFreeList()
-> coalBirth() in 
CompactibleFreeListSpace::addChunkToFreeListsAtEndRecordingStats()
-> coalBirth() in SweepClosure::flush_cur_free_chunk()
-> split_birth() in 
CompactibleFreeListSpace::getChunkFromLinearAllocBlock()

CompactibleFreeListSpace::splitChunkAndReturnRemainder()
-> split_birth() in CompactibleFreeListSpace::split()


So, all other calls than CompactibleFreeListSpace::reset() either 
increment the split birth or coal birth counters. When we set up the 
heap we eventually end up in the 
CompactibleFreeListSpace::addChunkToFreeListsAtEndRecordingStats() which 
increments the coal birth.

Since CompactibleFreeListSpace::reset() is called from 
CompactibleFreeListSpace::reset_after_compaction() when the freed up 
memory from the compaction is added to the free list it seems reasonable 
to update the same counter as when we first set up the heap. Thus, 
incrementing the coal birth seem more correct than incrementing the 
split birth count.

Thanks,
Bengt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130520/17d0dd25/attachment.htm>


More information about the hotspot-gc-dev mailing list