RFR: 8036025 - Sort the freelist in order to shrink the heap

[Jesper Wilhelmsson]

Thanks for reviewing Mikael!
/Jesper

Mikael Gerdin skrev 18/3/14 14:43:
> Jesper,
>
> On Tuesday 18 March 2014 12.51.47 Jesper Wilhelmsson wrote:
>> Hi,
>>
>> Recent changes in the GC code lead to non-trivial merge conflicts. I have
>> updated the change and here is a new webrev:
>>
>> http://cr.openjdk.java.net/~jwilhelm/8036025/webrev.3/
>
> Looks good.
> Thanks for adding the verification code for maintaining the ordered free
> lists.
> /Mikael
>
>>
>> The change itself should be the same but several name changes and cleanups
>> in related code was made that caused the conflicts.
>>
>> Thanks,
>> /Jesper
>>
>> Jesper Wilhelmsson skrev 4/3/14 02:14:
>>> Hi,
>>>
>>> I'm looking for reviews for this change in the freelist handling in G1.
>>>
>>> The problem is basically that if there are old regions that G1 choses not
>>> to collect or humongous regions near the top of the heap, G1 can not
>>> shrink the heap even though there is plenty of free space below these
>>> regions. Keeping the freelist sorted and trying to allocate old and
>>> humongous regions from the bottom of the heap while allocating young
>>> regions from the top of the heap will reduce the risk of encountering
>>> regions undesirable to evacuate in the top of the heap.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036025
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8036025/webrev/
>>>
>>> As performance testing we have run internal WLS benchmarks with good
>>> results. Keeping the regions sorted did not show any performance hit in
>>> these benchmarks.
>>>
>>> I also ran SPECjbb2005 for sanity and got good results:
>>>
>>> GC pauses without sorting:
>>> Count:  4673   Min:  0.0041562   Max:  0.0661340   Mean:  0.0324
>>>
>>> GC pauses with sorting:
>>> Count:  4116   Min:  0.0039851   Max:  0.0657399   Mean:  0.0323
>>>
>>> There are fewer GCs and the average pause time is about the same. There
>>> were two full GCs in each run. The heap size was smaller for a long time
>>> when sorting the freelist. Near the end of the benchmark it grew to the
>>> same size as the number of warehouses increased.
>>>
>>> I also look at the "Free CSet" time since this is where the insertion sort
>>> is happening to keep the list sorted.
>>>
>>> Without sorting:        Min:  0.0   Max:  2.2   Mean:  1.57
>>> With sorting:           Min:  0.0   Max:  2.4   Mean:  1.73
>>> With sorting 2:nd run:  Min:  0.0   Max:  1.9   Mean:  1.52
>>>
>>> What at first seemed as a slight regression is actually within the noise
>>> interval.
>>>
>>> The total SPECjbb score was improved with about 2%.
>>>
>>> Thanks,
>>> /Jesper
>