CRR (M): 7084509: G1: fix inconsistencies and mistakes in the young list target length calculations
tony.printezis at oracle.com
Thu Sep 1 09:43:41 UTC 2011
I fixed a couple of minor issues in the changes below, here's the
If you've already started looking at the previous one, here are the two
< double _reserve_regions;
> size_t _reserve_regions;
< "it's been updated to %u", G1ReservePercent);
> "it's been updated to %u", reserve_perc);
(with thanks to Bengt for pointing me to the first one)
On 08/30/2011 05:22 AM, Tony Printezis wrote:
> Hi all,
> I'd like one more review for this change (Bengt already reviewed it; I
> accidentally "stepped on his toes" with this refactoring, so we
> reviewed each other's changes to see how to move forward):
> This change fixed several issues in the young target length calculations:
> - There are two entry points to the calculation:
> calculate_young_list_target_length() and
> calculate_young_list_target_length(size_t rs_lengths). The former
> calls the latter, but in some cases the latter can be called by itself
> too. But there are some extra calculations (max survivor size, max GC
> locker expansion) that were not done when the latter was called by
> itself. Additionally, when calculate_young_list_target_length() was
> called it also required for another method to also be called
> beforehand (calculate_min_young_list_length()).
> Fix: replace the above with a single method,
> update_young_list_target_length() which takes an optional rs_lengths
> parameter. Everything is done inside it to ensure that everything that
> needs to be calculated, it is calculated and no other methods need to
> be called beforehand. This also ensures that if we want to apply any
> min / max bounds to the young target length, we can do so in a single
> - The max survivor size is done with an integer division. This means
> that, if the resulting value is between 0.0 and 1.0, the max survivor
> size will be 0 which effectively tenures everything during the next
> GC. It'd be better if it was 1.
> Fix: use double division and ceiling in order for the max survivor
> size to be 1 in the above case. Additionally, I now calculate the
> survivor parameters at the beginning of a pause instead of when the
> young target length is calculated / recalculated. Since those
> parameters only affect the next GC it's pointless to calculate /
> recalculate them earlier.
> - The code that calculates the optimal young target length (i.e., the
> max young length predicted to be within the required pause time) is
> embarrassingly incorrect. It uses binary search to yield the optimal
> length, but unfortunately exits early and in many situations returns a
> young target length that is shorter than it could be.
> Fix: updated the binary search algorithm to do the right thing. I
> compared the before / after calculations and the after calculation
> consistently yielded longer young target lengths which still fit
> within the required pause time.
> Additional fixes:
> - I now calculate the heap reserve every time the heap is resized (as
> it stays the same for a given heap size). There's no point in
> recalculating it every time we do the young target length calculations.
> - Refactoring and simplification to make the code easier to follow.
> This should help make the changes for the following two CRs easier:
> 6929868: G1: introduce min / max young gen size bounds
> 7084525: G1: Generate ergonomic decision log records for young gen
> sizing and for pause prediction
> The bulk of the changes are in G1CollectorPolicy. It might be easier
> if you looked at the new versions of the following methods:
> and compared them to the previous versions instead of looking at their
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev