Bug ID: 6604422 G1: re-use half-promoted regions

6604422 : G1: re-use half-promoted regions

Details

Type:	Enhancement	Submit Date:	2007-09-13
Status:	Resolved	Updated Date:	2010-04-04
Project Name:	JDK	Resolved Date:	2009-04-02
Component:	hotspot	OS:	generic
Sub-Component:	gc	CPU:	generic
Priority:	P3
Resolution:	Fixed
Affected Versions:	7
Fixed Versions:	hs15

Related Reports

Backport:	JDK-2177640 - G1: re-use half-promoted regions
Backport:	JDK-2180555 - G1: re-use half-promoted regions
Backport:	JDK-2183268 - G1: re-use half-promoted regions
Backport:	JDK-2175233 - G1: re-use half-promoted regions
Relates:	JDK-6817608 - G1: backports of G1 CRs from HS15 to HS14
Relates:	JDK-6862661 - G1: _gc_alloc_region_counts is not updated properly after 6604422
Relates:	JDK-6728271 - G1: Cleanup G1CollectedHeap::get_gc_alloc_regions()

Sub Tasks

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

2009-03-16

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.

2008-02-22

EVALUATION

See Comments.

2007-12-03

SELECT A COUNTRY/REGION
Africa Operation Argentina Australia Austria Bahrain Bangladesh Belgium & Luxembourg Belize Bhutan Bolivia Bosnia & Herzegovina Brasil Brunei Bulgaria Cambodia Canada - English Canada - French Chile China Colombia	Costa Rica Croatia Cyprus Czech Republic Denmark Ecuador Egypt Estonia Finland France Germany Greece Guatemala Honduras Hong Kong Hungary India Indonesia Iraq Ireland	Israel Italy Japan Jordan Kazakhstan Korea Kuwait Laos Latvia Lebanon Lithuania Malaysia Maldives Malta Mexico Moldova Nepal Netherlands New Zealand Nicaragua	Norway Oman Pakistan Panama Paraguay Peru Philippines Poland Portugal Puerto Rico Qatar Romania Russia Saudi Arabia Serbia & Montenegro Singapore Slovakia Slovenia South Africa Spain	Sri Lanka Sweden Switzerland -- French Switzerland -- German Taiwan Thailand Turkey Ukraine United Arab Emirates United Kingdom United States Uruguay Venezuela Vietnam Yemen

Hardware and Software, Engineered to Work Together