Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8314599

[GenShen] Couple adaptive tenuring and generation size budgeting

    XMLWordPrintable

Details

    • gc
    • Cause Known

    Description

      We should use object census information in generation size budgeting and further use generation sizing information in adaptive tenuring too so the two work well in tandem.

      Related advice from Kelvin:

      In final-mark, there are several actions that affect generation sizing, where there is opportunity to use the tenuring threshold for improved performance:

      1. `ShenandoahHeuristics::select_aged_regions()` returns the number of bytes to reserve for promotion, based only on the sum of live data contained within regions whose age is greater than tenure age. We use this value to set_promoted_reserve(). The callee takes this value and feeds it to ```heap->set_promoted_reserve()```. It would be better to do the following:

      ```
      size_t to_be_promoted = at_mark_census_tenure_age_or_above();
      size_t to_reserve_for_promotion = to_be_promoted * ShenandoahPromoEvacWaste;
      assert(consumed_by_advance_promotion <= to_reserve_for_promotion;
      heap->set_promoted_reserve(to_reserve_for_promotion);
      ```

      Actually, there's even more to this. We need to cap the promoted reserve at what is currently available within old to hold the results of promotion. You don't see this cap enforced in the current code because it is buried within the logic of `select_aged_regions()`. Regions will not be selected if their evacuation would cause us to exceed the available memory within old.

      2. In `ShenandoahGeneration::adjust_evacuation_budgets()`, we make the promoted_reserve "a little bit bigger", if it is convenient to do so, to reduce the likelihood of promotion failures, especially to promotion of objects that were not in "aged regions". This is no longer so critical, because we now know about almost all of the promotable objects that are not in aged regions (except for the dark matter). In any case, we need to make some refinements to this code if we can exploit info available from at-mark census.

      3. In `ShenandoahHeuristics::select_aged_regions()`, we invoke `heap->set_promotion_potential()` to be the total bytes of live memory contained within regions that are age 1 less than tenuring threshold if this is an aging cycle. This should change to:

      ```
      heap->set_promotion_potential(at_mark_census_one_less_than_tenure_age_if_aging() + deferred_promo_total)
      ```

      where `deferred_promo_total` is the sum of live data in tenure-aged regions that could not be preselected because there is not enough space in old-gen to receive their evacuations. Actually, we may want to refine the computation of `deferred_promo_total` to be `at_mark_census_tenure_age_or_above() - (old_gen_available_to_hold_evacuations / ShenandoahPromoEvacWaste)`.

      I can help you with this. Probably best to put all of this in a "follow-on" patch, but it would be nice to understand how your at-mark census would affect this behavior "in total".

      Attachments

        Issue Links

          Activity

            People

              ysr Y. Ramakrishna
              ysr Y. Ramakrishna
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - 1 day
                  1d
                  Remaining:
                  Remaining Estimate - 1 day
                  1d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified