JDK-8275638 : GraphKit::combine_exception_states fails with "matching stack sizes" assert
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-10-20
  • Updated: 2022-03-08
  • Resolved: 2021-12-17
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 17 JDK 18 JDK 19
17.0.4-oracleFixed 18 b29Fixed 19Fixed
Related Reports
Cloners :  
JDK-8278873 - GraphKit::combine_exception_states fails with "matching stack sizes" assert
Relates :  
JDK-4432078 - 2 JIT tests fail in comp mode only.
Relates :  
JDK-8271276 - C2: Wrong JVM state used for receiver null check
Relates :  
JDK-8278846 - C2: revisit exception propagation
Relates :  
JDK-8273165 - GraphKit::combine_exception_states fails with "matching stack sizes" assert
Relates :  
JDK-8278966 - two microbenchmarks tests fail "assert(!jvms->method()->has_exception_handlers()) failed: no exception handler expected" after JDK-8275638
Description
Even with the fix for JDK-8273165, I can still reproduce this:

java -XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0 -XX:+AlwaysIncrementalInline -XX:-TieredCompilation -Xbatch -XX:CompileThreshold=10 -XX:CompileCommand=dontinline,*DirectMethodHandle::allocateInstance

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/oracle/jdk/open/src/hotspot/share/opto/graphKit.cpp:348), pid=492513, tid=492526
#  assert(ex_jvms->sp() == phi_map->_jvms->sp()) failed: matching stack sizes

Current CompileTask:
C2:  12785 1313    b        jdk.internal.module.SystemModuleFinders$1::find (19 bytes)

Stack: [0x00007f9d5783a000,0x00007f9d5793b000],  sp=0x00007f9d57935b60,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd46d56]  GraphKit::combine_exception_states(SafePointNode*, SafePointNode*) [clone .part.0]+0xc6
V  [libjvm.so+0xd5204c]  GraphKit::replace_call(CallNode*, Node*, bool)+0x63c
V  [libjvm.so+0x8263db]  CallGenerator::do_late_inline_helper()+0xbbb
V  [libjvm.so+0x9fea4d]  Compile::inline_incrementally_one()+0x33d
V  [libjvm.so+0x9fedaf]  Compile::inline_incrementally(PhaseIterGVN&)+0x18f
V  [libjvm.so+0x9ffa09]  Compile::Optimize()+0x5e9
V  [libjvm.so+0xa026ae]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x159e
V  [libjvm.so+0x81d2b6]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x646
V  [libjvm.so+0xa12ae9]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd09
V  [libjvm.so+0xa13788]  CompileBroker::compiler_thread_loop()+0x518
V  [libjvm.so+0x1887f5c]  JavaThread::thread_main_inner()+0x27c
V  [libjvm.so+0x188e510]  Thread::call_run()+0x100
V  [libjvm.so+0x156de34]  thread_native_entry(Thread*)+0x104

We might need the same check added by JDK-8273165 in LateInlineMHCallGenerator::do_late_inline_check as well.
Comments
Fix Request (17u): Should get backported for parity with 17.0.4-oracle together with JDK-8278966. Applies cleanly. Test has passed.
07-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/200 Date: 2022-03-07 13:05:34 +0000
07-03-2022
[~roland] Unfortunately we are hitting the new assert assert(!jvms->method()->has_exception_handlers()) failed: no exception handler expected in some closed benchmarks. I'll investigate.
17-12-2021
Changeset: b9a477bf Author: Roland Westrelin <roland@openjdk.org> Date: 2021-12-17 07:46:47 +0000 URL: https://git.openjdk.java.net/jdk18/commit/b9a477bf19d9f276f6b1da8984eb56d7bd5fc137
17-12-2021
[~jrose], this issue seems related to an old issue, JDK-4432078, where the fix was to preserve the stack for exceptions (a while longer) rather than truncating immediately. I know it was a long time ago, but do you remember any details about that bug? In particular, how long does the stack need to be preserved, and at what point is it safe to truncate it?
30-11-2021
Vladimir, could you please have a look? I would assume we need a similar receiver non-null check in LateInlineMHCallGenerator::do_late_inline_check as well.
20-10-2021
ILW = Same as JDK-8273165 = P2
20-10-2021