JDK-8161147 : jvm crashes when -XX:+UseCountedLoopSafepoints is enabled
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u102,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-07-11
  • Updated: 2017-11-29
  • Resolved: 2016-07-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u131Fixed 9 b131Fixed openjdk7uFixed
Related Reports
Blocks :  
JDK-8155917 - Memory access in free regions during G1 full gc causes regressions in SPECjvm2008 scimark.fft,lu,sor,sparse with 9+116 on Linux-x64
Duplicate :  
JDK-8174144 - C2 crash in enabling -XX:+UseCountedLoopSafepoints flag
Relates :  
JDK-5014723 - implement "strip mining" loop optimization
Relates :  
JDK-8177693 - Java VM freezes with very simple program
Relates :  
JDK-8162603 - Unrecognized VM option 'UseCountedLoopSafepoints'
Relates :  
JDK-6869327 - Add new C2 flag to keep safepoints in counted loops.
Description
jvm crash with -XX:+UseCountedLoopSafepoints
Comments
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.
26-07-2016
Assigning this to [~roland], see discussions in: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023816.html
25-07-2016
could be related to JDK-8160287
11-07-2016
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 >
11-07-2016