JDK-6604422 : G1: re-use half-promoted regions
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-09-13
  • Updated: 2013-09-18
  • Resolved: 2009-04-02
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
JDK-6817608 - G1: backports of G1 CRs from HS15 to HS14
Relates :  
JDK-6728271 - G1: Cleanup G1CollectedHeap::get_gc_alloc_regions()
Relates :  
JDK-6862661 - G1: _gc_alloc_region_counts is not updated properly after 6604422
Description
Currently, G1 discards the last region promoted to after an evacuation pause and it does not re-use it during the next evacuation pause. This can result in a lot of half-full regions residing in the heap. We should ensure that the last region promoted to during an evacuation pause is also the first region promoted to during the subsequent evacuation pause. This was, G1 will utilize the heap a bit better.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6c4cea9bfa11
16-03-2009
EVALUATION A did a quick test and, interestingly, my fix for this bug does not seem to be affecting how often marking cycles happen (i.e., two runs, one with and one without the fix, do the same number of marking cycles and those cycles are similarly spaced apart). It actually makes sense, as in both cases, the marking cycle is initiated when the used space in the heap is over a given limit. However, in the run without the fix, some of the space that is free, resides in several half-full regions that we might not be able to allocate from Whereas, in the run with the fix, the space that is free resides in more totally empty regions. So, the latter case has less of a chance of getting a concurrent marking failure (as there's actually more free space available for allocation). So, the fix is still worth incorporating.
22-02-2008
EVALUATION See Comments.
03-12-2007