Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8192992

compiler/c2/Test8007294.java coalesce.cpp...assert(false) failed: attempted to spill a non-spillable item

    Details

    • Subcomponent:
    • CPU:
      x86_64
    • OS:
      linux

      Description

      #
      # A fatal error has been detected by the Java Runtime Environment:
      #
      # Internal Error (/workspace/open/src/hotspot/share/opto/coalesce.cpp:298), pid=17394, tid=17419
      # assert(false) failed: attempted to spill a non-spillable item: 594: testN_mem_reg0, ireg = 13, spill_type: PhiInputSpillCopy
      #
      # JRE version: Java(TM) SE Runtime Environment (10.0) (fastdebug build 10-internal+0-jdk10-hs.401)
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 10-internal+0-jdk10-hs.401, mixed mode, compressed oops, g1 gc, linux-amd64)
      #

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

      Command Line: -Dtest.class.path.prefix=/testoutput/jtreg/JTwork/classes/0/compiler/c2/Test8007294.d:/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk10-hs.401/src.full/open/test/hotspot/jtreg/compiler/c2 -Dtest.src=/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk10-hs.401/src.full/open/test/hotspot/jtreg/compiler/c2 -Dtest.src.path=/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk10-hs.401/src.full/open/test/hotspot/jtreg/compiler/c2 -Dtest.classes=/testoutput/jtreg/JTwork/classes/0/compiler/c2/Test8007294.d -Dtest.class.path=/testoutput/jtreg/JTwork/classes/0/compiler/c2/Test8007294.d -Dtest.vm.opts=-XX:MaxRAMPercentage=8 -Dtest.tool.vm.opts=-J-XX:MaxRAMPercentage=8 -Dtest.compiler.opts= -Dtest.java.opts=-XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation -Dtest.jdk=/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk10-hs.401/linux-x64-debug.jdk/jdk-10/fastdebug -Dcompile.jdk=/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk10-hs.401/linux-x64-debug.jdk/jdk-10/fastdebug -Dtest.timeout.factor=10.0 -Dtest.nativepath=/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk10-hs.401/linux-x64-debug.test/hotspot/jtreg/native -XX:MaxRAMPercentage=8 -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -Djava.library.path=/scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk10-hs.401/linux-x64-debug.test/hotspot/jtreg/native -XX:+IgnoreUnrecognizedVMOptions -XX:+AlwaysIncrementalInline -XX:-UseOnStackReplacement -XX:-BackgroundCompilation com.sun.javatest.regtest.agent.MainWrapper /testoutput/jtreg/JTwork/compiler/c2/Test8007294.d/main.0.jta

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

      Current thread (0x00007f40783a0800): JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=17419, stack(0x00007f4050b4f000,0x00007f4050c50000)]


      Current CompileTask:
      C2: 3988 538 b jdk.internal.loader.URLClassPath::getResource (74 bytes)

      Stack: [0x00007f4050b4f000,0x00007f4050c50000], sp=0x00007f4050c4ae00, 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+0x182f8b2] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162
      V [libjvm.so+0x183067f] VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
      V [libjvm.so+0xb3868d] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
      V [libjvm.so+0xa31375] PhaseAggressiveCoalesce::insert_copies(Matcher&)+0x2805
      V [libjvm.so+0x909dc4] PhaseChaitin::Register_Allocate()+0x2c4
      V [libjvm.so+0xa9c829] Compile::Code_Gen()+0x3a9
      V [libjvm.so+0xaa00ba] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x130a
      V [libjvm.so+0x8b87c2] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x2e2
      V [libjvm.so+0xaaa9fe] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x38e
      V [libjvm.so+0xaab5f1] CompileBroker::compiler_thread_loop()+0x241
      V [libjvm.so+0x178629a] JavaThread::thread_main_inner()+0x21a
      V [libjvm.so+0x17864da] JavaThread::run()+0x17a
      V [libjvm.so+0x14bad4a] thread_native_entry(Thread*)+0xfa
      C [libpthread.so.0+0x7dc5] start_thread+0xc5
      1. hs_err_pid17394.log
        103 kB
        Ioi Lam
      2. hs_err_pid22272.log
        103 kB
        Tobias Hartmann
      3. replay_pid22272.log
        153 kB
        Tobias Hartmann

        Issue Links

          Activity

          Hide
          neliasso Nils Eliasson added a comment -
          I can add that adding -XX:+TraceLoopOpts makes the compilation crash in verify_compare.
          Show
          neliasso Nils Eliasson added a comment - I can add that adding -XX:+TraceLoopOpts makes the compilation crash in verify_compare.
          Hide
          thartmann Tobias Hartmann added a comment -
          Sounds like JDK-8173709 but shouldn't verify_compare only be executed if VerifyLoopOptimizations is set?
          Show
          thartmann Tobias Hartmann added a comment - Sounds like JDK-8173709 but shouldn't verify_compare only be executed if VerifyLoopOptimizations is set?
          Hide
          roland Roland Westrelin added a comment -
          What about bailing out with C2Compiler::retry_no_subsuming_loads() and re-attempting compilation? See clone_node() in reg_split.cpp for instance.
          Show
          roland Roland Westrelin added a comment - What about bailing out with C2Compiler::retry_no_subsuming_loads() and re-attempting compilation? See clone_node() in reg_split.cpp for instance.
          Hide
          neliasso Nils Eliasson added a comment - - edited
          Thanks Roland,

          I implemented your suggestion but had trouble reproducing the issue. The code in the JDK that causes this was removed Dec 5 by [~redestad] (this bug was opened Dec 4th):

          hangeset: 48194:6c4bdbf90897
          user: redestad
          date: Tue Dec 05 22:26:17 2017 +0100
          summary: 8193064: JarFile::getEntry0 method reference use cause for startup regression

          So this isn't even a P3 anymore.

          I will fix this but suggest targeting to 11
          Show
          neliasso Nils Eliasson added a comment - - edited Thanks Roland, I implemented your suggestion but had trouble reproducing the issue. The code in the JDK that causes this was removed Dec 5 by [~redestad] (this bug was opened Dec 4th): hangeset: 48194:6c4bdbf90897 user: redestad date: Tue Dec 05 22:26:17 2017 +0100 summary: 8193064: JarFile::getEntry0 method reference use cause for startup regression So this isn't even a P3 anymore. I will fix this but suggest targeting to 11
          Hide
          thartmann Tobias Hartmann added a comment -
          Okay, let's defer this to JDK 11 then. It would be good if we could create a regression test.
          Show
          thartmann Tobias Hartmann added a comment - Okay, let's defer this to JDK 11 then. It would be good if we could create a regression test.

            People

            • Assignee:
              neliasso Nils Eliasson
              Reporter:
              iklam Ioi Lam
            • Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated: