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

Early reclamation of large objects in G1

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: hs25, 8
    • Fix Version/s: 9
    • Component/s: hotspot
    • Subcomponent:
      gc
    • Resolved In Build:
      b28

      Backports

        Description

        In G1 large objects are always allocated in the old generation, requiring a complete heap liveness analysis (full gc, marking) to reclaim them.

        This is far from ideal for many transaction based enterprise applications that create large objects that are only live until a (typically short-lived) transaction is not completed (e.g. in a ResultSet of a JDBC query that generates a large result).
        This results in the heap filling up relatively quickly, typically leading to unnecessary marking cycles just to reclaim them.

        Investigate options to reclaim these objects more quickly; options found so far are:
        a) logically keep LOBs in young gen, doing in-place aging
        b) keep LOBs in the old gen, but use the remembered set and information from young collection to determine LOB liveness

          Issue Links

            Activity

            Hide
            tschatzl Thomas Schatzl added a comment -
            Actually it is not required to put the humongous objects into the collection set - it is sufficient to make references to them pass the G1CollectedHeap::in_cset_fast test in G1ParCopyClosure::do_oop_work.

            Putting the humongous objects (even temporarily) into the collection set gives issues with remembered set updates not occurring any more.

            Current prototype changes in_cset_fast_test to include humongous objects (actually not all calls to G1CollectedHeap::in_cset_fast_test() should be changed, but that's a minor detail) - first tests indicate that this is indistinguishable in performance from the original code (more testing needed), while the first prototype increased the "Object Copy" time by ~10%.
            Show
            tschatzl Thomas Schatzl added a comment - Actually it is not required to put the humongous objects into the collection set - it is sufficient to make references to them pass the G1CollectedHeap::in_cset_fast test in G1ParCopyClosure::do_oop_work. Putting the humongous objects (even temporarily) into the collection set gives issues with remembered set updates not occurring any more. Current prototype changes in_cset_fast_test to include humongous objects (actually not all calls to G1CollectedHeap::in_cset_fast_test() should be changed, but that's a minor detail) - first tests indicate that this is indistinguishable in performance from the original code (more testing needed), while the first prototype increased the "Object Copy" time by ~10%.
            Hide
            tschatzl Thomas Schatzl added a comment -
            In reply to the previous comment:

            >Putting the humongous objects (even temporarily) into the collection set gives issues with remembered set updates not occurring any more.
            >
            >Current prototype changes in_cset_fast_test to include humongous objects (

            There are no issues with remembered set updates when temporarily putting the humongous object into the _in_cset_fast_test collection set test because during rset update we use the _in_collection_set member of the heapregion, not the in_cset_fast_test.
            Show
            tschatzl Thomas Schatzl added a comment - In reply to the previous comment: >Putting the humongous objects (even temporarily) into the collection set gives issues with remembered set updates not occurring any more. > >Current prototype changes in_cset_fast_test to include humongous objects ( There are no issues with remembered set updates when temporarily putting the humongous object into the _in_cset_fast_test collection set test because during rset update we use the _in_collection_set member of the heapregion, not the in_cset_fast_test.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/07a6e56a6936
            User: tschatzl
            Date: 2014-07-23 08:06:46 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/07a6e56a6936 User: tschatzl Date: 2014-07-23 08:06:46 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/07a6e56a6936
            User: lana
            Date: 2014-08-28 21:56:57 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/07a6e56a6936 User: lana Date: 2014-08-28 21:56:57 +0000
            Hide
            tschatzl Thomas Schatzl added a comment -
            The current implementation uses separate values for humongous regions and regions in the collection set, so the comments about issues in the remembered set are obsolete.
            Show
            tschatzl Thomas Schatzl added a comment - The current implementation uses separate values for humongous regions and regions in the collection set, so the comments about issues in the remembered set are obsolete.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: