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

[Jesper Wilhelmsson]

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%:
Without sorting:  163084
With sorting:     166442

Thanks,
/Jesper