JDK-8051344 : JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u20,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2014-07-18
  • Updated: 2017-08-07
  • Resolved: 2014-07-28
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
8u40Fixed 9 b28Fixed
Description
JVM crashed in Compile::start() w/ UseRTMDeopt and UseRTMForStackLocks turned on.
I was able to reproduce issue on linux host only with both product and fastdebug builds:

Stack: [0x00007f1c9e55c000,0x00007f1c9e65d000],  sp=0x00007f1c9e659d90,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x48603b]  Compile::start() const+0xb
V  [libjvm.so+0x858a5a]  LoadNode::Ideal(PhaseGVN*, bool)+0x25a
V  [libjvm.so+0x927d89]  PhaseGVN::transform_no_reclaim(Node*)+0x29
V  [libjvm.so+0x5dd112]  GraphKit::make_load(Node*, Node*, Type const*, BasicType, int, MemNode::MemOrd, bool)+0xc2
V  [libjvm.so+0x90b333]  Parse::rtm_deopt()+0xf3
V  [libjvm.so+0x90d5fd]  Parse::Parse(JVMState*, ciMethod*, float, Parse*)+0x73d
V  [libjvm.so+0x3e7009]  ParseGenerator::generate(JVMState*, Parse*)+0x99
V  [libjvm.so+0x49248c]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x125c
V  [libjvm.so+0x3e5ae8]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x198
V  [libjvm.so+0x49acda]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a
V  [libjvm.so+0x49d6b0]  CompileBroker::compiler_thread_loop()+0x620
V  [libjvm.so+0xa277af]  JavaThread::thread_main_inner()+0xdf
V  [libjvm.so+0xa278dc]  JavaThread::run()+0x11c
V  [libjvm.so+0x8e4828]  java_start(Thread*)+0x108
C  [libpthread.so.0+0x79d1]

Current CompileTask:
C2:1277573 29160 %     4       article2html::topLevel @ 34 (183 bytes)

With fastdebug builds following assert fails:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/072614.amurillo/s/src/share/vm/opto/compile.cpp:1157), pid=4150, tid=140362568251136
#  assert(!failing()) failed: 
#
# JRE version: Java(TM) SE Runtime Environment (8.0_20-b22) (build 1.8.0_20-ea-fastdebug-b22)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.40-b02-internal-201407110726.amurillo.hs25-40-b02-set-ve-fastdebug mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: /export/local/aurora/sandbox/results/kitchensink/core or core.4150
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Current thread (0x00007fa8cc343cf8):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=4216, stack(0x00007fa8b4f53000,0x00007fa8b5054000)]

Stack: [0x00007fa8b4f53000,0x00007fa8b5054000],  sp=0x00007fa8b50504c0,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xfb1d6a]  VMError::report_and_die()+0x2da
V  [libjvm.so+0x71ad64]  report_vm_error(char const*, int, char const*, char const*)+0x84
V  [libjvm.so+0x682cd6]  Compile::start() const+0x46
V  [libjvm.so+0xc7fa49]  LoadNode::Ideal(PhaseGVN*, bool)+0x129
V  [libjvm.so+0xdb611f]  PhaseGVN::transform_no_reclaim(Node*)+0x3f
V  [libjvm.so+0x88ee30]  GraphKit::make_load(Node*, Node*, Type const*, BasicType, int, MemNode::MemOrd, bool)+0x120
V  [libjvm.so+0xd8256a]  Parse::rtm_deopt()+0x15a
V  [libjvm.so+0xd8960a]  Parse::Parse(JVMState*, ciMethod*, float, Parse*)+0xa5a
V  [libjvm.so+0x572689]  ParseGenerator::generate(JVMState*, Parse*)+0xb9
V  [libjvm.so+0x693aa3]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1483
V  [libjvm.so+0x570111]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x2c1
V  [libjvm.so+0x6a181e]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xace
V  [libjvm.so+0x6a2754]  CompileBroker::compiler_thread_loop()+0x5f4
V  [libjvm.so+0xf39491]  JavaThread::thread_main_inner()+0x221
V  [libjvm.so+0xf3979d]  JavaThread::run()+0x2bd
V  [libjvm.so+0xd48268]  java_start(Thread*)+0x108
C  [libpthread.so.0+0x79d1]

Current CompileTask:
C2:1471321 23086 %     4       article2html::topLevel @ 34 (183 bytes)

Issue could be reproduced starting from 8u20-b08 when RTM support was integrated.
Comments
Issue: JVM crash in Compile::start during method parsing when UseRTMDeopt is used. Root cause: We're adding uncommon trap for RTM state change after method entry setup, but before check for bailouts happened during method entry setup. So if compilation failed during method entry setup, we either crash in Parse::rtm_deopt while trying to access start block (which is NULL after Compile::record_failure call) or fail on assert inside Compile::start. Suggested fix: Check for bailouts before calling Parse::rtm_deopt.
21-07-2014

Issue does not actually depend on UseRTMForStackLocks.
21-07-2014

I started kitchensink w/ updated hsx build to ensure that it will resolve the issue.
18-07-2014

Send webrev with the fix.
18-07-2014

Without RTM: 1378936 33872 % 4 article2html::topLevel @ 34 (183 bytes) COMPILE SKIPPED: OSR starts with non-empty stack (retry at different tier)
18-07-2014

Vladimir, I'll check it without RTM, but with RTM it bails out on lower tiers: 1361431 33136 % 3 article2html::topLevel @ 34 (183 bytes) COMPILE SKIPPED: stack not empty at OSR entry point (retry at different tier)
18-07-2014

Filipp, so if RTM is not used this compilation will bail out (check PrintCompilation)? If yes, then your suggestion is correct. Thanks!
18-07-2014

Looks like Parse1::rtm_deopt should be placed after bailouts check: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/opto/parse1.cpp#l580
18-07-2014

It is also reproducible on Solaris.
18-07-2014

Crash always happen during compilation of one particular method: article2html::topLevel Looks like this class (article2html) is generated in runtime.
18-07-2014