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

G1 crash during concurrent root region scan

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 8u60, 9
    • Fix Version/s: 11
    • Component/s: hotspot
    • Subcomponent:
      gc
    • Resolved In Build:
      master
    • CPU:
      generic
    • OS:
      generic

      Description

      We have seen crashes with G1 during concurrent root region scan.
      It turned out that the reason for the crashes was reloading an oop after a null check.
      The compiler may legally do this, as the pointer is not declared as volatile.
      The code runs concurrently to mutator threads.


      template <class T>
      inline void G1RootRegionScanClosure::do_oop_nv(T* p) {
        T heap_oop = oopDesc::load_heap_oop(p); // 1. load
        if (!oopDesc::is_null(heap_oop)) {
          oop obj = oopDesc::decode_heap_oop_not_null(heap_oop); // 2. Compiler decides to reload
          HeapRegion* hr = _g1h->heap_region_containing((HeapWord*) obj);
          _cm->grayRoot(obj, obj->size(), _worker_id, hr);
        }
      }


      We have seen the problem on AIX with the xlC compiler. However, we have seen similar optimizations on other platforms.

      As this code pattern is used quite often throughout the whole jvm, I would suggest a global fix in oopDesc::load_heap_oop(p).

        Issue Links

          Activity

          Hide
          jwilhelm Jesper Wilhelmsson added a comment -
          Further info from Axel:

          We have seen the bug on aix ppc. It affects 8u and 9.
          The crash happened sporadically, but we were able to identify the root cause by analyzing the assembly generated by the xlC compiler.
          Though, we have seen crashes on just this one platform, there could be a problem on other platforms, if the compiler decides to optimize in the described way.
          Show
          jwilhelm Jesper Wilhelmsson added a comment - Further info from Axel: We have seen the bug on aix ppc. It affects 8u and 9. The crash happened sporadically, but we were able to identify the root cause by analyzing the assembly generated by the xlC compiler. Though, we have seen crashes on just this one platform, there could be a problem on other platforms, if the compiler decides to optimize in the described way.
          Show
          simonis Volker Simonis added a comment - Axel posted a webrev for this issue here: http://cr.openjdk.java.net/~asiebenborn/8129440/webrev.00/ And this is the mail thread where the issue has been discussed: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/thread.html#13924 http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-July/thread.html#14078
          Hide
          tschatzl Thomas Schatzl added a comment - - edited
          This should be fixed after the barrier API changes (JDK-8178890): for loads from the heap that may be concurrent, add a decorator to the load to make those volatile instead of making all load_heap_oop() equivalents volatile.
          Show
          tschatzl Thomas Schatzl added a comment - - edited This should be fixed after the barrier API changes (JDK-8178890): for loads from the heap that may be concurrent, add a decorator to the load to make those volatile instead of making all load_heap_oop() equivalents volatile.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk/hs/rev/2569f227ae8e
          User: tschatzl
          Date: 2018-01-11 10:34:09 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk/hs/rev/2569f227ae8e User: tschatzl Date: 2018-01-11 10:34:09 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk/jdk/rev/2569f227ae8e
          User: jwilhelm
          Date: 2018-01-19 16:54:42 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk/jdk/rev/2569f227ae8e User: jwilhelm Date: 2018-01-19 16:54:42 +0000

            People

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

              Dates

              • Created:
                Updated:
                Resolved: