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

Rebuild remembered sets during the concurrent cycle

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9, 10
    • Fix Version/s: 11
    • Component/s: hotspot
    • Subcomponent:
      gc
    • Resolved In Build:
      b10

      Description

      G1 maintains remembered sets for all old regions at any time. This poses
      a significant footprint and throughput overhead. The footprint overhead
      is the result of storing the remembered set information, the throughput
      overhead results from executing the slow paths of the post-write barrier
      and the refinement work.

      Some remembered sets need to be maintained always, i.e. the ones for the
      young generation to allow evacuation. However, G1 only actually needs
      the remembered sets for the old gen regions G1 intends to evacuate
      during and while executing a mixed GC phase.

      In many larger applications the old gen remembered sets are much larger
      than the young gen ones.

      Given a way to rebuild the remembered sets on demand, these observations
      may allow us to avoid managing the remembered sets for a large part of
      the heap most of the time:
      - all of them during the young-only phase
      - old regions without marking information ("to" regions since the last
         concurrent mark cycle)
      - old regions with too many live objects to make them worth evacuating
      - humongous regions
      - any other regions that we are not going to collect for any reason.
         E.g. the user can set a global/local footprint overhead, a liveness
         threshold, or use any other information about the application.

      The suggestion here is to use concurrent mark for rebuilding remembered
      sets. Concurrent mark already traverses the entire object graph, so it
      can determine the remembered sets for any given region in conjunction
      with the barriers. While this will significantly lengthen the concurrent
      mark phase, the benefits for throughput and memory footprint may
      outweigh this, resulting in an overall win.

      (from http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November/019217.html)

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: