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

Mikael Gerdin mikael.gerdin at oracle.com
Tue Mar 18 13:43:02 UTC 2014


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




More information about the hotspot-gc-dev mailing list