JDK-8036025 : Sort the freelist in order to shrink the heap
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u20,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-02-28
  • Updated: 2015-10-28
  • Resolved: 2014-03-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u20Fixed 9 b08Fixed
Related Reports
Duplicate :  
JDK-8028053 - Reduce region fragmentation by separating region allocations by type
Relates :  
JDK-8037925 - CMM Testing: an allocated humongous object at the end of the heap should not prevents shrinking the heap
Relates :  
JDK-7002407 - G1: Improve free region management
Description
The G1 heap can currently only shrink from the top down. In applications that allocates lots of large objects this can become a problem since G1 does not move large objects. If a large object happens to be allocated near the top of the heap, G1 will not be able to shrink the heap even if there is plenty of free space below the large object.

Old regions that G1 gives a low priority to collect will also stop the heap from shrinking in a similar manner. As long as there are old regions near the top of the heap, G1 can not shrink the heap.

One way to lower the risk of allocating large objects and old regions near the top of the heap is to sort the free list and make sure that we always try to claim these regions near the bottom of the heap.
Comments
Long lived objects will end up in old regions. With this change we will make an effort to allocate old regions at the lowest addresses in the heap, instead of anywhere as was the case before. Fragmentation in terms of free consecutive regions will still be a problem, mainly due to large objects, but in the benchmarks we have run this change reduces the fragmentation. A free hole in the middle of the heap will not help us shrink the heap or decommit the backing pages (currently). The only way the machine could use the RAM "freed" by having a free hole in the middle of the heap is by swapping out the unused parts of the Java heap. There is some ideas in this area but the current GCs would not behave well with a swapped out heap.
10-04-2014
I haven't looked at the change, just the description above... Wouldn't this cause the heap to fragment since the long lived objects are now breaking up the contiguous address range somewhat more? One might want to get an online trace of large object allocations (from some typical applications) and compare the two policies to see which is better wrt keeping the heap from getting fragmented vs being able to shrink the heap. Since virtual address space is not an issue, but only physical memory, why not just free up the physical pages corresponding to the free regions in the middle of the heap? Does the presence of this free hole in the heap cause issues with something else?
09-04-2014