JDK-6765745 : par compact - allow young gen spaces to be split
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-10-30
  • Updated: 2010-04-02
  • Resolved: 2009-01-31
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-6330863 - vm/gc/InfiniteList.java fails intermittently due to timeout problems
Relates :  
JDK-6810474 - par compact - crash in summary_phase with very full heap
Relates :  
JDK-6765954 - par compact - stress mode for splitting young gen spaces
Relates :  
JDK-6784849 - par compact - can fail when to_space is non-empty
Relates :  
JDK-6679764 - enable parallel compaction by default
Description
During a full gc, all live objects in the young gen are copied to the old gen as long as there is enough space.  When the heap is very full, all the young gen objects may not fit.  With par compaction, this often results in a long series of time-consuming full gcs which do not free up space in eden.  When par compact is copying from a young gen space (e.g., eden or from) to the old gen, *all* live objects in the space must fit into the old gen; otherwise, none of them will be copied.  This is because par compaction operates on fixed-size 'regions' of the heap and copying only part of a space would require extra bookkeeping (or some good luck).

The extra bookkeeping should be implemented to allow a young gen space to be "split" so that as much as will fit is copied to the old gen and the rest is compacted down within the young gen space itself.
Comments
SUGGESTED FIX Attached.
12-12-2008
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7c2386d67889
12-12-2008
EVALUATION Since par compact operates on fixed-size regions of the heap, a space can only be split at a region boundary to avoid dramatically slowing down the calculation of the new location of a pointer (a very hot code path). Since objects cannot be split, a split must be done at a region boundary that is not spanned by a live object. When a split is necessary (very full heap), such boundaries are scarce. Par compact already keeps track of partial objects--which are the tail ends of objects which span region boundaries. Given this and a little extra bookkeeping, a region can be split just after the end of a partial object without affecting hot code paths. When splitting a region, the partial object and everything to its left will be copied to another space (call it destination space 1, or d1). The live data to the right of the partial object will be copied either within the space itself, or to another destination space (d2, which is distinct from d1). Since the partial object will have no effect on the locations of other objects destined for d2, the data about the partial object can be saved in a side data structure and removed from the main summary table (summary_data). More specifically, when the par compact summary phase determines that a region needs to be split, it records the following in a separate "SplitInfo" table: the region being split the size of the partial object crossing onto the region the destination address of the first word of the partial object the destination count of the partial object (the number of regions it will be copied to--1 or 2) the destination region boundary (if it will be copied to 2 regions) the address of the first word within the partial object to be copied to the second destination region (again if it will be copied to 2 regions) A space is split at most once, so the amount of data is small and fixed size. The info is needed only when finding the first word to be copied to a destination region, which is done once per region and so has no noticeable effect on performance. The tricky part is recording the data properly during the summary phase.
30-10-2008