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

Refactor G1s usage of save_marks and reduce related races

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Subcomponent:
      gc
    • Resolved In Build:
      b43

      Backports

        Description

        G1 currently uses the _saved_mark_word field in Space to detemine a point in a region above which a current GC cannot scan objects. This is needed to prevent card scanning threads from scanning in memory regions where other gc workers are concurrently allocating objects.

        This re-use of the _saved_mark_word field causes confusion to readers of the code since it's not used for the same purpose as the other Space classes.
        The setting and reading of this field, and the per region gc time stamp which accompanies it is also unnecessarily racy. Previously the _saved_mark_word field was set to the value of the _top pointer when a region was selected as a GC allocation region and the time stamp was set to indicate that the saved mark field should be used as a maximum address. This code had some problems with races in JDK-8058209 and could be redesigned in a less racy way.

        Suggested fix is to introduce a new field in HeapRegions to keep track of the maximum address where card scanning is allowed and set that field at the point of retaining an OldGCAllocRegion instead of when allocations are being started. That way we get rid of the store ordering requirement in the timestamp record path.

        There is still a race between the per region time stamps and the per region top pointer, where we must ensure that the time stamp store must be visible before any subsequent top stores.
        This store ordering is enforced by the fact that all stores to top are either ordered with #storestore (the initial allocation) or guarded by a Mutex. To ensure that the reader path sees a consistent view it must be exectued with the proper load ordering, where we must read top before the time stamp in order to ensure that we don't see a top value which has been updated by a concurrent gc worker if we see a time stamp from a previous gc cycle.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  mgerdin Mikael Gerdin (Inactive)
                  Reporter:
                  mgerdin Mikael Gerdin (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: