JDK-7084509 : G1: fix inconsistencies and mistakes in the young list target length calculations
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs22
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-08-29
  • Updated: 2013-10-04
  • Resolved: 2011-09-30
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 7 JDK 8 Other
7u2Fixed 8Fixed hs22Fixed
Related Reports
Relates :  
Relates :  
Description
The code that sets / calculates G1's young list target length has many
inconsistencies and mistakes. The include:

a) There are two entry points:

* calculate_young_list_target_length(), for use when ergonomics are or
  are not enabled.

* calculate_young_list_target_length(size_t rs_lengths), for use when
  ergonomics are enabled and the calculation needs to be revised due
  to RS lengts being measured to be longer than the last prediction.

Unfortunately, the latter does not seem to recalculate several values
including the max GC locker expansion and the max survivor region
number, both of which are based on the calculated target length.

b) There is no obvious place to bound the final young target length
with a desired min and/or max length, given that it's done differently
(and in a way: redundantly) for the two entry points described in a).

c) The max survivor region number calculation is done with an integer
division and it is not taking into account the fact that the resulting
value could be between 0.0 and 1.0. This meant that, in some cases,
the max survivor number is set to 0.

d) The code the calculates the optimal young list length target using
a binary search is incorrect and exits earlier than it should without
finding an optimal result. The reason for this is that it is written
in a way that it keeps halving the distance between min and max length
by decreasing max length, until it finds a length that fits into the
pause time target. But it then stops, instead of attempting to
increase max length (while still halving the distance between min and
max length). This means that, even though the result fits into the
pause time target, it is not optimal and there are longer lengths that
will also fit into the pause time target.

Comments
EVALUATION See main CR
12-09-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4f41766176cf
08-09-2011

PUBLIC COMMENTS This is related to 6929868 and 7084525 it will make the implementation of those two CRs much more straightforward.
29-08-2011

EVALUATION See Description and Evaluation.
29-08-2011

SUGGESTED FIX Introduce a unified update_young_list_target_length(), with an optional rs_lengths parameter, which can be used in all the places where calculate_young_list_target_length() and calculate_young_list_target_length(rs_lengths) were used before and without needing any extra method calls beforehand like before. Now, any necessary bounding of the young target length can be done in update_young_list_target_length(). The max GC locker expansion is also correctly recalculated every time the young list target length is recalculated. The calculations of the survivor parameters (max survivor region num and tenuring threshold) are now done at the beginning of a GC instead of after the calculation of the young list target length. Given that they only take effect during the next GC, it ss pointless to recalculate them every time we recalculate the young list target length. I also updated the max survivor region num calculation to return 1 in the case where the result is between 0.0 and 1.0. The calculation of the reserve size is now done after the heap is expanded or shrunk. It's again pointless to do it every time we recalculate the young list target length given that, for a given heap size, the reserve size remains the same. Fixed the binary search to really calculate the optimal young list target length and added post-conditions to check that this is the case.
29-08-2011