JDK-6949241 : G1: restructure region lists in G1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs18,7
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2010-05-03
  • Updated: 2019-02-11
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8034079 - G1: Refactor the HeapRegionSet hierarchy
Relates :  
JDK-6868854 - G1: Eliminate serial Other times at the end of a GC pause
Relates :  
JDK-7092309 - G1: introduce old region set
Relates :  
JDK-6977804 - G1: remove the zero-filling thread
Relates :  
JDK-7002407 - G1: Improve free region management
Description
In G1 we maintain a lot of region lists (collection set list, young regions list, etc.) but we do so in ad-hoc and inconsistent ways. That code is also very error-prone: one change on this code is known to be followed-up with several assertion failures. We would like to restructure the region lists in G1 to make the code more consistant and easier to maintain. Main requirements of this change are:

- Use a top-level G1HeapRegionList class to maintain all lists (with possible specialized subclasses)
- Each heap region will belong to exactly one list at any time and have a single next field
- The heap region lists will maintain the used space for the entire heap.
Comments
It would be better to completely move out the next field(s). This would allow us to keep a particular region within *multiple* lists which allows several other optimizations (apart from that it makes heapregions independent of the data structure used to maintain them). Also all heap region sets should be aware of their members. - allows using different specialized containers adapted to the situation. - take a "snapshot" of the current heap to simplify marking. The current method to skip regions committed during marking is somewhat racy (although benign) and makes the code more complicated than it is - allows iteration of some specific types of regions without iterating over the whole heap and having additional (often repeated) code to skip over certain types of regions. Also fix const'ness and general unusual coding style.
14-07-2014
PUBLIC COMMENTS We have already done parts of this when we introduced the free region list and humongous region set as part of: 6977804: G1: remove the zero-filling thread The second part is to keep track of the old regions in the old region set, which will be done as part of: 7092309: G1: introduce old region set We will use this CR for the remaining work, which is to to introduce region lists for the eden and survivor regions.
19-09-2011