JDK-8179882 : C2: Stale control info after cast node elimination during loop optimization pass
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-05-08
  • Updated: 2019-09-13
  • Resolved: 2017-05-30
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 10 JDK 9
10Fixed 9 b173Fixed
Related Reports
Relates :  
JDK-8139771 - Eliminating CastPP nodes at Phis when they all come from a unique input may cause crash
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f1b0f24b58e, pid=21016, tid=21300
#
# JRE version: Java(TM) SE Runtime Environment (9.0+167) (build 9-ea+167)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+167, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xa2058e]  PhaseIdealLoop::build_loop_late_post(Node*)+0x13e
#

From jdk/test/java/util/concurrent/tck/JSR166TestCase.java

---------------  T H R E A D  ---------------

Current thread (0x00007f1b082de000):  JavaThread "C2 CompilerThread8" daemon [_thread_in_native, id=21300, stack(0x00007f1a108f1000,0x00007f1a109f2000)]


Current CompileTask:
C2:  10142 2842       4       Collection8Test::lambda$adderRemover$48 (41 bytes)

Stack: [0x00007f1a108f1000,0x00007f1a109f2000],  sp=0x00007f1a109ece80,  free space=1007k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xa2058e]  PhaseIdealLoop::build_loop_late_post(Node*)+0x13e
V  [libjvm.so+0xa20953]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x133
V  [libjvm.so+0xa231a2]  PhaseIdealLoop::build_and_optimize(bool, bool)+0x7c2
V  [libjvm.so+0x6065ee]  Compile::Optimize()+0x98e
V  [libjvm.so+0x607e27]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1027
V  [libjvm.so+0x532632]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x1d2
V  [libjvm.so+0x60fe5c]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x41c
V  [libjvm.so+0x610ce3]  CompileBroker::compiler_thread_loop()+0x273
V  [libjvm.so+0xcea848]  JavaThread::thread_main_inner()+0xd8
V  [libjvm.so+0xb69a32]  thread_native_entry(Thread*)+0xf2
C  [libpthread.so.0+0x7aa1]
Comments
Thanks, Igor.
30-05-2017
Thanks, Vladimir.
30-05-2017
Approved for JDK 9.
30-05-2017
Fix Request The bug is a regression in 9 - JDK-8139771, which introduced it, was integrated only in 9. The bug can manifest itself as a JVM crash during JIT-compilation. It's hard to estimate the impact, so it's safer to fix the bug. The fix is small and focused: it touches only the code introduced by JDK-8139771.
29-05-2017
The 'Fix Request' request comment is missing. Please, add it with all information.
29-05-2017
jdk9-fix-request: http://cr.openjdk.java.net/~vlivanov/8179882/webrev.01/
29-05-2017
RFR: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026334.html
24-05-2017
Suggested fix: diff --git a/src/share/vm/opto/loopopts.cpp b/src/share/vm/opto/loopopts.cpp --- a/src/share/vm/opto/loopopts.cpp +++ b/src/share/vm/opto/loopopts.cpp @@ -914,6 +914,11 @@ if (n->is_ConstraintCast()) { Node* dom_cast = n->as_ConstraintCast()->dominating_cast(this); if (dom_cast != NULL) { + Node* n_ctrl = get_ctrl(n); + Node* dom_cast_ctrl = get_ctrl(dom_cast); + if (!is_dominator(dom_cast_ctrl, n_ctrl)) { + set_ctrl_and_loop(dom_cast, dom_lca(dom_cast_ctrl, n_ctrl)); + } _igvn.replace_node(n, dom_cast); return dom_cast; }
24-05-2017
(IGV screenshot is attached.) There are 2 CastPP nodes in play: 733 CastPP === 1230 677 [[ ... ]] Oop:java/lang/Object:NotNull * !jvms: ... 5846 CastPP === 1581 677 [[ ... ]] carry dependency Oop:java/lang/Object:NotNull * ... !jvms: ... 733 dominates 5846 and the latter one is replaced, though it carries control dependency. There are 2 users of those CastPP nodes: 773 CheckCastPP === 1260 733 [[ ... ]] Oop:java/lang/Integer:NotNull:exact * !jvms: ... 574 CheckCastPP === 1260 5846 [[ ... ]] Oop:java/lang/Integer:NotNull:exact * !jvms: ... After 5846 is replaced 733, the same transformation replaces 773 with 574, though they belong to different loops: 773 CheckCastPP === 1260 733 [[ ... ]] Oop:java/lang/Integer:NotNull:exact * !jvms: ... 574 CheckCastPP === 1260 733 [[ ... ]] Oop:java/lang/Integer:NotNull:exact * !jvms: ... In other words, it moves 574 from N4445 loop to N4442, but _igvn.replace_node(n, dom_cast) doesn't fix loop bodies: Loop: N4442/N1838 limit_check predicated body={ ... 773 ... } Loop: N4445/N2197 limit_check predicated body={ ... 574 ... } So, after the transformation N4442 misses 574 node and on the very next attempt to peel N4442 an incomplete loop body is cloned which leads to broken IR and the crash.
22-05-2017
ILW = Crash/assert in C2, rare but able to reproduce with replay compilation, disable loop optimizations or -XX:+UseParallelGC = HMM = P2
08-05-2017
I'm able to reproduce this with attached replay compilation file: bin/java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid21016.log -XX:+PrintCompilation # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:3565 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/HUDSON/workspace/9-2-build-linux-amd64-phase2/jdk9/6060/hotspot/src/share/vm/opto/loopnode.cpp:3565), pid=21871, tid=21998 # assert(false) failed: Bad graph detected in build_loop_late It's a regression in JDK 9 b156. I'll try to find the change that caused the problem.
08-05-2017
Steps to reproduce: 1) Run jtreg test: jtreg -jdk:/oracle/8179882/build/linux-x86_64-normal-server-fastdebug/jdk/ -va test/java/util/concurrent/tck/JSR166TestCase.java 2) Set class path (can be obtained from the jtreg log file): export CLASSPATH=/oracle/8179882/jdk/JTwork/classes/java/util/concurrent/tck:/oracle/8179882/jdk/test/java/util/concurrent/tck:/home/tohartma/programs/jtreg/lib/junit.jar:/home/tohartma/programs/jtreg/lib/javatest.jar:/home/tohartma/programs/jtreg/lib/jtreg.jar 3) Execute replay compilation file: /oracle/8179882/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid21016.log
08-05-2017
I did binary search on the changesets added in JDK 9 b156. The problem was not introduced by any hotspot change but triggered by JDK-8171886 which modified classes in java/util/concurrent used by the test.
08-05-2017