JDK-8218968 : C1 compilation fails with assert(stack_end >= -Bytecodes::depth(code)) failed: must have non-empty expression stack at if bytecode
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-02-14
  • Updated: 2019-02-14
  • Resolved: 2019-02-14
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 13
13Resolved
Related Reports
Duplicate :  
JDK-8218721 - C1's CEE optimization produces safepoint poll with invalid debug information
Description
#  Internal Error (/oracle/jdk_jdk/open/src/hotspot/share/c1/c1_LinearScan.cpp:2382), pid=28024, tid=28049
#  assert(stack_end >= -Bytecodes::depth(code)) failed: must have non-empty expression stack at if bytecode

Current CompileTask:
C1:    530   29    b  1       compiler.c1.TestGotoIf::test (19 bytes)

Stack: [0x00007fa6fab21000,0x00007fa6fac22000],  sp=0x00007fa6fac1fce0,  free space=1019k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x845366]  check_stack_depth(CodeEmitInfo*, int)+0x216
V  [libjvm.so+0x85d676]  LinearScan::compute_debug_info(CodeEmitInfo*, int)+0x46
V  [libjvm.so+0x85e45f]  LinearScan::assign_reg_num(GrowableArray<LIR_Op*>*, IntervalWalker*)+0x58f
V  [libjvm.so+0x85e6e3]  LinearScan::assign_reg_num()+0xa3
V  [libjvm.so+0x86b31d]  LinearScan::do_linear_scan()+0x1dd
V  [libjvm.so+0x78b994]  Compilation::emit_lir()+0x1024
V  [libjvm.so+0x78ccc6]  Compilation::compile_java_method()+0x6e6
V  [libjvm.so+0x78dad9]  Compilation::compile_method()+0x2d9
V  [libjvm.so+0x78e8d4]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x4f4
V  [libjvm.so+0x790aab]  Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x18b
V  [libjvm.so+0xa9a0d0]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x3c0
V  [libjvm.so+0xa9aedf]  CompileBroker::compiler_thread_loop()+0x3bf
V  [libjvm.so+0x182817f]  JavaThread::thread_main_inner()+0x21f
V  [libjvm.so+0x182e2d0]  Thread::call_run()+0x100
V  [libjvm.so+0x146e67d]  thread_native_entry(Thread*)+0xfd

The bytecodes are: 
         0: aload_0 
         1: getfield #36 
         4: aload_0 
         5: getfield #22 
         8: iconst_1 
         9: isub 
        10: if_icmpgt 15 
        13: iconst_1 
        14: ireturn 
        15: iconst_0 
        16: goto 14
Comments
Okay, after further investigation, I'm certain that this is just another failure mode of JDK-8218721. Closing.
14-02-2019
Right but my current understanding is that it does not affect product code. What about: ILW = Assert during C1 compilation (does not affect product), easy to reproduce with jasm test but should not happen with javac generated code, disable compilation of affected method = MMM = P3
14-02-2019
[~thartmann], the fact that javac doesn't generate such code doesn't make L=L as there are other java-compiler, bytecode instrumentation frameworks, etc which might produce such bytecode. so I'd say it's HMM => P2
14-02-2019
Regression test: http://cr.openjdk.java.net/~thartmann/8218968/webrev.00/
14-02-2019
ILW = Assert during C1 compilation, easy to reproduce with jasm test but should not happen with javac generated code, disable compilation of affected method = HLM = P3
14-02-2019