JDK-8160782 : assert(!_reg_node[reg_lo] || edge_from_to(_reg_node[reg_lo],def)) failed: before block local scheduling on solaris-sparcv9
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • CPU: sparc
  • Submitted: 2016-07-04
  • Updated: 2019-09-13
  • Resolved: 2017-03-06
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.
Related Reports
Duplicate :  
Relates :  
Relates :  
JDK-6776584: "Escape analysis on sparcv9: Error: before block local scheduling" was fixed in (JDK-8068881). But issue is still reproducible. 

Host:  Sun Sparcv9 3600 MHz, 8 cores, 16G, Solaris / Solaris 11, sun4v
VM options: -Xcomp -server -XX:+CreateCoredumpOnCrash -XX:+IgnoreUnrecognizedVMOptions -XX:ReservedCodeCacheSize=256M 

The hs_err head is 
# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error (/opt/jprt/T/P1/235228.amurillo/s/hotspot/src/share/vm/opto/output.cpp:2527), pid=44965, tid=30
#  assert(!_reg_node[reg_lo] || edge_from_to(_reg_node[reg_lo],def)) failed: before block local scheduling
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-07-01-235228.amurillo.jdk9-hs-2016-06-30-snapshot)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-07-01-235228.amurillo.jdk9-hs-2016-06-30-snapshot, compiled mode, tiered, compressed oops, g1 gc, solaris-sparc)
# Core dump will be written. Default location: /export/home/aurora/sandbox/results/base_domain/core or core.44965
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp

---------------  S U M M A R Y ------------

Command Line: -Xcomp -XX:+CreateCoredumpOnCrash -XX:+IgnoreUnrecognizedVMOptions -XX:ReservedCodeCacheSize=256M -Xcomp -Djava.net.preferIPv6Addresses=false -Xmx8096M -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData -Xlog:gc*:gc.log -XX:+DisableExplicitGC -XX:+PrintFlagsFinal -Djdk.launcher.addexports.0=java.base/sun.net.www.protocol.file=ALL-UNNAMED -Djdk.launcher.addexports.1=java.base/sun.net.www=ALL-UNNAMED -Djdk.launcher.addexports.2=java.base/sun.nio.fs=ALL-UNNAMED -Djdk.launcher.addexports.3=java.corba/com.sun.corba.se.spi.ior=ALL-UNNAMED -Djdk.launcher.addexports.4=java.corba/com.sun.corba.se.spi.transport=ALL-UNNAMED -Djdk.launcher.addexports.5=java.corba/com.sun.corba.se.spi.legacy.connection=ALL-UNNAMED -Djdk.launcher.addexports.6=java.corba/com.sun.corba.se.spi.ior.iiop=ALL-UNNAMED -Djdk.launcher.addexports.7=java.corba/com.sun.corba.se.spi.orb=ALL-UNNAMED -Djdk.launcher.addexports.8=java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED -Djdk.launcher.addexports.9=java.xml.bind/com.sun.xml.internal.bind.marshaller=ALL-UNNAMED -Djdk.launcher.addexports.10=jdk.javadoc/com.sun.tools.doclets.standard=ALL-UNNAMED -Djdk.launcher.addexports.11=java.corba/org.omg.TimeBase=ALL-UNNAMED -Djdk.launcher.addexports.12=java.corba/org.omg.CORBA.ValueDefPackage=ALL-UNNAMED -Djdk.launcher.addexports.13=java.base/sun.nio.ch=ALL-UNNAMED -Djdk.launcher.addexports.14=java.base/java.io=ALL-UNNAMED -Djdk.launcher.addexports.15=java.xml/com.sun.org.apache.xml.internal.resolver=ALL-UNNAMED -Djdk.launcher.addexports.16=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED -Djdk.launcher.addexports.17=java.xml/com.sun.org.apache.xerces.internal.jaxp.validation=ALL-UNNAMED -Djdk.launcher.addexports.18=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED -Djdk.launcher.addexports.19=java.base/com.sun.net.ssl=ALL-UNNAMED -Djdk.launcher.addexports.20=jdk.rmic/sun.rmi.rmic=ALL-UNNAMED -Djdk.launcher.addexports.21=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED -Djdk.launcher.addexports.22=java.desktop/sun.swing=ALL-UNNAMED -Djdk.launcher.addexports.23=java.desktop/sun.awt.shell=ALL-UNNAMED -Djdk.launcher.addexports.24=java.desktop/sun.font=ALL-UNNAMED -Djdk.launcher.addmods=java.corba,jdk.rmic,java.xml.bind -Djdk.upgrade.module.path=/export/home/aurora/CommonData/bigapps_testbase/fakejdk9/up119 -Djdk.module.path=/export/home/aurora/CommonData/bigapps_testbase/fakejdk9/mp -Djdk.launcher.patch.0=java.corba=/export/home/aurora/CommonData/bigapps_testbase/fakejdk9/patches/java.corba.jar weblogic.Server

Host: sca00dbd, Sparcv9 64 bit 3600 MHz, 8 cores, 15G, Oracle Solaris 11.2 SPARC
Time: Sat Jul  2 07:55:37 2016 UTC elapsed time: 2537 seconds (0d 0h 42m 17s)

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

Current thread (0x000000010061f000):  JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=30, stack(0xffffffff43400000,0xffffffff43500000)]

Current CompileTask:
C2:2537573 98672   !b  4       com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl::apply (408 bytes)

Stack: [0xffffffff43400000,0xffffffff43500000],  sp=0xffffffff434faa90,  free space=1002k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1aa06c8]  void VMError::report_and_die(int,const char*,const char*,void*,Thread*,unsigned char*,void*,void*,const char*,int,unsigned long)+0xaa8
V  [libjvm.so+0x1a9fbac]  void VMError::report_and_die(Thread*,const char*,int,const char*,const char*,void*)+0x3c
V  [libjvm.so+0xcbe4f8]  void report_vm_error(const char*,int,const char*,const char*,...)+0x78
V  [libjvm.so+0x16cf060]  void Scheduling::verify_good_schedule(Block*,const char*)+0x6e0
V  [libjvm.so+0x16d0060]  void Scheduling::ComputeRegisterAntidependencies(Block*)+0x30
V  [libjvm.so+0x16ce210]  void Scheduling::DoScheduling()+0x650
V  [libjvm.so+0x16cb9ac]  void Compile::ScheduleAndBundle()+0xdc
V  [libjvm.so+0x16c4bf4]  void Compile::Output()+0x7f4
V  [libjvm.so+0xc10ff4]  void Compile::Code_Gen()+0x624
V  [libjvm.so+0xc05964]  Compile::Compile #Nvariant 1(ciEnv*,C2Compiler*,ciMethod*,int,bool,bool,bool,DirectiveSet*)+0x1374
V  [libjvm.so+0xa11774]  void C2Compiler::compile_method(ciEnv*,ciMethod*,int,DirectiveSet*)+0x124
V  [libjvm.so+0xc2b364]  void CompileBroker::invoke_compiler_on_method(CompileTask*)+0x714
V  [libjvm.so+0xc2a2c8]  void CompileBroker::compiler_thread_loop()+0x308
V  [libjvm.so+0x19e1ac4]  void JavaThread::thread_main_inner()+0x2e4
V  [libjvm.so+0x19e1740]  void JavaThread::run()+0x370
V  [libjvm.so+0x16a6ed4]  thread_native_entry+0x414
C  [libc.so.1+0xe4af0]  _lwp_start+0x8

I have spent ~80 machine hours (~16 hours on the particular machine on which the problem was last manifested) trying to provoke the error/assert without success. If there are no objections (or great ideas) I will close the issue by the end of the day (or as soon as the system is willing...).

Unable to reproduce error/assert despite ~100 machine hours of testing. The files manifesting the problem when last encountered in Aurora has been lost and no new core file or test scenario has been successfully provoked during the dedicated test-runs. The nature of this assert is such that it may catch problems from a wide range of sources/transforms (even though RA is the closest "neighbour").

Updated priority according to Igor's suggestion, added hs-comp-triaged label.

retargeting to jdk9 and putting to critical watch list.

ILW=release criteria broken; c2, sparc only, rare;none=HLH=>P2

I agree w/ Igor here, this issue can be serious, so before we defer it from jdk9 we need to assess impact on end users.

Hi Patric, this is a SPARC-specific issue. Could you please look into it / keep track of it? Thank you! Best regards, Zoltan

Thanks, Igor. I'll look into it.

Sorry, I'd have to move it back to you. I didn't really have time to look at it. It's targeted to JDK10, but could be potentially quite serious. Could you please, perhaps, ask somebody from QE to help setup Medrec to just with JDK9? If we can make it start and the replay would work (cause the compiler to crash) please move it back to me, I'll debug it.

Thanks for looking into this. It would be great if you could spend some time on this. If you don't have time now (and you also expect not to have any before ZBB), please assign the bug to me.

This is a generic symptom of a graph breakage after register allocation. A use is preceding the def. It's hard to tell anything more without looking at the graph. 95% of the work here would be to reproduce the problem.

ILW = assert; rare; none = MLH = P4

Hi Igor, you've looked at similar (or maybe the same) problem before. Would you have time for this issue? If not, can you maybe give an assessment of the problem? Please feel free to assign the issue to me at any time. Best regards, Zoltan

ILW = crash; rarely/fastdebug; none = HLH = P2