RFR (S): 8014971: Minor code cleanup of the freelist management

[Bengt Rutisson]

Thanks for the reviews, Jesper, Jon and Thomas!

Pushing this now.

Thomas, I removed the commented out line that you mentioned.

Bengt

On 5/21/13 3:35 PM, Bengt Rutisson wrote:
>
> Hi all,
>
> While fixing 'JDK-7066063: CMS: "Conservation Principle" assert 
> failed' I made some code cleanups in the code I was browsing. I didn't 
> want to mix these changes in with the bug fix, so I'm submitting this 
> review for those changes. Could I have a couple of reviews of this 
> small cleanup?
>
> http://cr.openjdk.java.net/~brutisso/8014971/webrev.00/
>
> Here is what I did:
>
> - Removed the unused constructors for FreeList and AdaptiveFreeList
> - Removed unnecessary NULL check after call to global operator new. 
> The new operator already checks the allocation and exits the VM if it 
> fails.
> - Removed unused old_end variable in 
> ConcurrentMarkSweepGeneration::grow_by().
> - Fixed a possible bug in 
> CompactibleFreeListSpace::addChunkToFreeListsAtEndRecordingStats()
>
> The last fix may require some explanation. In the constructor for 
> CompactibleFreeListSpace() we set up the _indexedFreeListParLocks 
> array. But we only set it up if ParallelGCThreads > 0, so if we are 
> single threaded the locks are unintialized (not even NULL, just random 
> values). In 
> CompactibleFreeListSpace::addChunkToFreeListsAtEndRecordingStats() we 
> use these locks but we don't check for ParallelGCThreads > 0. We only 
> check the chunk size to see if there is a chance that the chunk may 
> end up in the smaller buckets. This will fail if ParallelGCThreads = 0.
>
> This bug is benign since 
> CompactibleFreeListSpace::addChunkToFreeListsAtEndRecordingStats() is 
> only used when we grow or shrink the generation. This is always done 
> with os::vm_allocation_granularity() which is larger than 
> SmallForDictionary so we will never enter the dangerous code path. 
> However, if someone in the future either increases the value of 
> SmallForDictionary or uses a smaller alignment for the generation 
> sizing we might hit this problem. So, I figured it is worth leaving 
> the code but making sure that it works properly.
>
> Thanks,
> Bengt