United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7084509 G1: fix inconsistencies and mistakes in the young list target length calculations
JDK-7084509 : G1: fix inconsistencies and mistakes in the young list target length calculations

Details
Type:
Bug
Submit Date:
2011-08-29
Status:
Closed
Updated Date:
2013-10-04
Project Name:
JDK
Resolved Date:
2011-09-30
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs22
Fixed Versions:
hs22 (b05)

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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
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.
                                     
2011-08-29
EVALUATION

See Description and Evaluation.
                                     
2011-08-29
PUBLIC COMMENTS

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

See main CR
                                     
2011-09-12
EVALUATION

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



Hardware and Software, Engineered to Work Together