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

jvm crashes when -XX:+UseCountedLoopSafepoints is enabled

    Details

    • Subcomponent:
    • Resolved In Build:
      b131

      Backports

        Description

        jvm crash with -XX:+UseCountedLoopSafepoints

          Issue Links

            Activity

            Hide
            kvn Vladimir Kozlov added a comment -
            Roman reported related issue, I think:

            On 7/11/16 9:53 AM, Roman Kennke wrote:
            > I noticed that it sometimes takes up to 20 seconds to reach a safepoint
            > when running the scimark benchmark of SPECjvm2008.
            >
            > It looks to me like scimark is just triple nested loops with finite
            > bounds, which translates to a CountedLoop, and safepoints are removed
            > unconditionally from counted loops if no outer loops needs them (which
            > doesn't seem to be the case). Therefore, a Java thread inside such a
            > loop can only reach a safepoint when it exits the outermost loop, and
            > this can take a while.
            >
            > This seems like a rather serious bug to me. This prevents GC from
            > kicking in, deoptimizations, biased locking and probably some other
            > things from responding in a timely manner. Even just killing the app
            > with CTRL+C seems to be affected.
            >
            > Is this a known issue? Any ideas how a proper fix looks like?
            >
            > It can be reproduced with SPECjvm2008 like this:
            >
            > java -XX:+SafepointTimeout -jar SPECjvm2008.jar -ict -ikv scimark
            >
            > (If you have a very fast machine, you probably have to pass
            > -XX:SafepointTimeoutDelay with a value lower than 10000, I think
            > 10seconds is much too generous anyway)
            >
            >
            > BTW, I tried -XX:+UseCountedLoopSafepoints, and it does indeed solve
            > the problem, but ran into other problems in SPECjvm2008's compiler
            > benchmarks:
            >
            > java -XX:+UseCountedLoopSafepoints -XX:+SafepointTimeout
            > -XX:SafepointTimeoutDelay=2000 -jar SPECjvm2008.jar -ict -ikv compiler
            >
            > .. fails with:
            >
            > #
            > # A fatal error has been detected by the Java Runtime Environment:
            > #
            > # SIGSEGV (0xb) at pc=0x00007f7adff09814, pid=23268, tid=23296
            > #
            > # JRE version: OpenJDK Runtime Environment (9.0) (fastdebug build 9-
            > internal+0-2016-07-11-184003.rkennke.jdk9)
            > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 9-internal+0-2016-07-11-
            > 184003.rkennke.jdk9, mixed mode, tiered, compressed oops, g1 gc, linux-
            > amd64)
            > # Problematic frame:
            > # V [libjvm.so+0xfb0814] PhaseIdealLoop::get_ctrl(Node*)+0x64
            >
            Show
            kvn Vladimir Kozlov added a comment - Roman reported related issue, I think: On 7/11/16 9:53 AM, Roman Kennke wrote: > I noticed that it sometimes takes up to 20 seconds to reach a safepoint > when running the scimark benchmark of SPECjvm2008. > > It looks to me like scimark is just triple nested loops with finite > bounds, which translates to a CountedLoop, and safepoints are removed > unconditionally from counted loops if no outer loops needs them (which > doesn't seem to be the case). Therefore, a Java thread inside such a > loop can only reach a safepoint when it exits the outermost loop, and > this can take a while. > > This seems like a rather serious bug to me. This prevents GC from > kicking in, deoptimizations, biased locking and probably some other > things from responding in a timely manner. Even just killing the app > with CTRL+C seems to be affected. > > Is this a known issue? Any ideas how a proper fix looks like? > > It can be reproduced with SPECjvm2008 like this: > > java -XX:+SafepointTimeout -jar SPECjvm2008.jar -ict -ikv scimark > > (If you have a very fast machine, you probably have to pass > -XX:SafepointTimeoutDelay with a value lower than 10000, I think > 10seconds is much too generous anyway) > > > BTW, I tried -XX:+UseCountedLoopSafepoints, and it does indeed solve > the problem, but ran into other problems in SPECjvm2008's compiler > benchmarks: > > java -XX:+UseCountedLoopSafepoints -XX:+SafepointTimeout > -XX:SafepointTimeoutDelay=2000 -jar SPECjvm2008.jar -ict -ikv compiler > > .. fails with: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f7adff09814, pid=23268, tid=23296 > # > # JRE version: OpenJDK Runtime Environment (9.0) (fastdebug build 9- > internal+0-2016-07-11-184003.rkennke.jdk9) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 9-internal+0-2016-07-11- > 184003.rkennke.jdk9, mixed mode, tiered, compressed oops, g1 gc, linux- > amd64) > # Problematic frame: > # V [libjvm.so+0xfb0814] PhaseIdealLoop::get_ctrl(Node*)+0x64 >
            Hide
            kvn Vladimir Kozlov added a comment -
            could be related to JDK-8160287
            Show
            kvn Vladimir Kozlov added a comment - could be related to JDK-8160287
            Hide
            thartmann Tobias Hartmann added a comment -
            Show
            thartmann Tobias Hartmann added a comment - Assigning this to [~roland], see discussions in: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023816.html
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/286ad75013e2
            User: kvn
            Date: 2016-07-25 23:41:45 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/286ad75013e2 User: kvn Date: 2016-07-25 23:41:45 +0000
            Hide
            thartmann Tobias Hartmann added a comment - - edited
            This also affects JDK 8u:
            # Internal Error (/oracle/jdk8u-dev/hotspot/src/share/vm/opto/loopnode.hpp:669), pid=10144, tid=0x00007f981ddca700
            # assert(has_ctrl(i)) failed:

            Added affects version and 8-bp label.
            Show
            thartmann Tobias Hartmann added a comment - - edited This also affects JDK 8u: # Internal Error (/oracle/jdk8u-dev/hotspot/src/share/vm/opto/loopnode.hpp:669), pid=10144, tid=0x00007f981ddca700 # assert(has_ctrl(i)) failed: Added affects version and 8-bp label.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/286ad75013e2
            User: lana
            Date: 2016-08-10 20:19:27 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/286ad75013e2 User: lana Date: 2016-08-10 20:19:27 +0000

              People

              • Assignee:
                roland Roland Westrelin
                Reporter:
                shadowbug Shadow Bug
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: