JDK-8219448 : split-if update_uses accesses stale idom data
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2019-02-20
  • Updated: 2024-10-18
  • Resolved: 2019-03-07
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 11 JDK 12 JDK 13 JDK 8
11.0.4Fixed 12.0.2Fixed 13 b12Fixed 8u431Fixed
Related Reports
Duplicate :  
JDK-8218067 - C2 crashes in PhaseIdealLoop::split_up
Relates :  
JDK-8215757 - C2: PhaseIdealLoop::create_new_if_for_predicate() computes wrong IDOM
Relates :  
JDK-8218067 - C2 crashes in PhaseIdealLoop::split_up
Relates :  
JDK-8210832 - Remove sneaky locking in class Monitor
Relates :  
JDK-8218067 - C2 crashes in PhaseIdealLoop::split_up
Description
Found this assert/crash from the Lucene CI when looking for another assert.

https://jenkins.thetaphi.de/job/Lucene-Solr-8.0-Linux/194/

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/opto/split_if.cpp:322), pid=20957, tid=21005
#  assert(prior_n->is_Region()) failed: must be a post-dominating merge point
#
# JRE version: OpenJDK Runtime Environment (12.0) (fastdebug build 12-testing+0-builds.shipilev.net-openjdk-jdk12-b109-20190215-jdk-1229)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 12-testing+0-builds.shipilev.net-openjdk-jdk12-b109-20190215-jdk-1229, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x17da240]  PhaseIdealLoop::spinup(Node*, Node*, Node*, Node*, Node*, small_cache*) [clone .part.43]+0x330
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Comments
Thanks Aleksey!
02-05-2019
Yeah. I also requested the backport for JDK-8218067. Please don't put redhat-openjdk on your own :)
02-05-2019
Thanks Uwe. [~shade], do you want to take care of backporting this to JDK 11? I'm marking this issue as 'redhat-openjdk' for now.
02-05-2019
Fix Request (11u, 12u) Backporting this patch resolves a JVM crash (apparently seen with Solr). Patch applies cleanly to 11u and 12u, passes tier{1,2} tests with Linux x86_64 fastdebug. Changes look safe to Roland.
02-05-2019
Hi, this also seems to help for JDK-8218067, the problems are not shouwing up anymore. As Lucene/Solr master branch has JDK 11 minimum requirement, it would be good to have this in the JDK-11 LTS. Would it be possible to fix this there, as this is a serious crash appearing in Apache Solr.
01-05-2019
URL: http://hg.openjdk.java.net/jdk/jdk/rev/a37939761ff6 User: neliasso Date: 2019-03-07 21:17:50 +0000
07-03-2019
[~uschindler] This is under going final review. I will push it to JDK repo as soon as possible.
07-03-2019
Is there a build available for linux x64 with this? If not I can try to patch and build on my own, so we can see if this also fixes the SEGV caused by JDK-8218067.
02-03-2019
http://cr.openjdk.java.net/~neliasso/8219448/webrev.01/
28-02-2019
With the patched replay file I have been able to reproduce on 13, and been able to find the cause. When doing spilt-if - the idom is not properly updated below the if-region being split. This usually doesn't matter, but in this case there are other uses of dependent on phis in the split-region. When we are trying to find new places for the phis, we use old idom data and do bad transforms.
27-02-2019
The patch changes the size of a Mutex, and a Mutex is inlined into every MethodData. When a JDK13 reads a JDK12 replay-file - offsets will be wrong. In this case the repro stops to work, but the bug might still be there. So this is probably still an issue with 13, I just don't have a replay-file that works with 13. RFE - Let ciReplay dump and verify size of MethodData.
22-02-2019
This change is the one that fixes the problem in JDK13. I just can't see how - seems totally unrelated. changeset: 53646:043ae846819f user: pchilanomate date: Tue Feb 05 15:12:13 2019 -0500 summary: 8210832: Remove sneaky locking in class Monitor
21-02-2019
The bug is fixed between jdk13+6 and jdk13+7
21-02-2019
Doesn't reproduce on 13.
20-02-2019
- Clone git clone https://github.com:apache/lucene-solr.git cd lucene-solr git checkout master_8_0 - Build (You will need to bootstrap ivy, and install ant) cd lucene ant jar JDK12: - Grab or build a fastdebug jdk12: - Reproduce: ~/git/lucene-solr/lucene$ .../jdk12/build/linux-x64-debug/images/jdk/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid20957.log -XX:+ReplayIgnoreInitErrors -XX:-SplitIfBlocks -cp ./build/analysis/common/classes/java:./build/core/classes/java
20-02-2019
Reproduces with jdk/jdk12 top. -XX:-SplitIfBlocks works as a workaround
20-02-2019
Pre-ILW = Crash in split if optimization, intermittent but reproducible with Lucene CI, disable split if (-XX:-SplitIfBlocks) or compilation of affected method = HMM = P2
20-02-2019
Looks like JDK-8215757 but that has been fixed.
20-02-2019
Linking other lucene bug. That one has been around for quite a while. Only commonality is split_if
20-02-2019
Current CompileTask: C2: 11245 2473 4 org.apache.lucene.analysis.miscellaneous.TrimFilter::incrementToken (138 bytes) Stack: [0x00007f149d5fe000,0x00007f149d6ff000], sp=0x00007f149d6f9060, free space=1004k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x17da240] PhaseIdealLoop::spinup(Node*, Node*, Node*, Node*, Node*, small_cache*) [clone .part.43]+0x330 V [libjvm.so+0x17da3a0] PhaseIdealLoop::spinup(Node*, Node*, Node*, Node*, Node*, small_cache*) [clone .part.43]+0x490 V [libjvm.so+0x17db669] PhaseIdealLoop::handle_use(Node*, Node*, small_cache*, Node*, Node*, Node*, Node*, Node*)+0x119 V [libjvm.so+0x17e1e54] PhaseIdealLoop::do_split_if(Node*)+0x25b4 V [libjvm.so+0x128c4c1] PhaseIdealLoop::split_if_with_blocks_post(Node*, bool)+0xe91 V [libjvm.so+0x128c5a1] PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&, bool)+0xc1 V [libjvm.so+0x1282a0a] PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x127a V [libjvm.so+0xa36df9] Compile::Optimize()+0x3a9 V [libjvm.so+0xa38dbb] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x13db V [libjvm.so+0x82fd88] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x2e8 V [libjvm.so+0xa4562b] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x35b V [libjvm.so+0xa462f8] CompileBroker::compiler_thread_loop()+0x1e8 V [libjvm.so+0x1908f27] JavaThread::thread_main_inner()+0x1e7 V [libjvm.so+0x1904865] Thread::call_run()+0x75 V [libjvm.so+0x14da750] thread_native_entry(Thread*)+0x110
20-02-2019