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

Clean up evacuation of optional collection set

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 12
    • Fix Version/s: 13
    • Component/s: hotspot
    • Subcomponent:
      gc
    • Resolved In Build:
      b16

      Description

      In JDK-8190269/JDK-8213890 we added abortable mixed gc, ie. parts of the collection set during mixed gc were collected incremementally as pause time permitted.

      Some of these issues have been pointed out in reviews, but moved for later.

      There are a quite a few opportunities to clean up the code:
      - the optional collection set evacuation duplicates quite a bit of "first pass" evacuation code while conceptually very similar. This should be unified and cleaned up as much as possible.
      - with the optional collection set the code creates copies of parts of the candidate collection set, first popping it from it and then pushing back leftovers. This is not necessary, an index (cursor) within the candidate collection set is sufficient.

      Some imho benign real issues with the current implementation, that are partially caused by the code duplication:
      - if there is an evacuation failure during evacuating an optional part, we try to fix up self-looped oops for the entire collection set which is not necessary. Obviously only regions part of the current collection pass need to be looked at.
      - the work distribution when evacuating an optional collection set is bad: every thread processes the same regions in the same sequence
      - calculation of total number of cards scanned and total scan RS time does not take optional evacuation into account
      - optional collection set log does not show code roots time (from the heap region's remembered sets) and termination time completely
      - optional collection also does not add "code root fixup time"
      - optional collection does not add to the "par time" (which is actually the time for the parallel evacuation), which means that the calculation for the "Other" time is wrong (result too high) impacting prediction (being too conservative)
      - the opt_index_in_cset of a heap region is not reset for all regions every time after GC. Since it is properly overwritten as needed this seems benign.

      Note that since the amount of optional regions/additional passes over the remembered set are typically rather small, there is no real performance problem.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tschatzl Thomas Schatzl
                Reporter:
                tschatzl Thomas Schatzl
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: