JDK-8336702 : C2 compilation fails with "all memory state should have been processed" assert
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16,17,21,23,24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2024-07-08
  • Updated: 2025-08-13
  • Resolved: 2024-10-09
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 21 JDK 24
21.0.9Fixed 24 b19Fixed
Related Reports
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

$ java -version
openjdk version "23-internal" 2024-09-17
OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.jdk23u)
OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.jdk23u, mixed mode)

A DESCRIPTION OF THE PROBLEM :
When we run the following test case using jdk23u (latest code from GitHub), the JVM crashes. We also tested other JDKs and found that jdk17u has the same issue, while jdk21-release does not have this problem, nor does jdk8u. Additionally, running jdk23u with the -Xint parameter does not cause any issues.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
javac Test.java && java Test

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
run without exception
ACTUAL -
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/data/jdk23u/src/hotspot/share/opto/loopnode.cpp:711), pid=2117538, tid=2118042
#  assert(mm == nullptr|| _igvn.transform(mm) == mem->as_MergeMem()->base_memory()) failed: all memory state should have been processed
#
# JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-internal-adhoc.jdk23u)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.jdk23u, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x12ad786]  PhaseIdealLoop::find_safepoint(Node*, Node*, IdealLoopTree*)+0xe26
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /data/toreport/Test2200_07_05_10_00_52/reduce/core.2117538)
#
# An error report file with more information is saved as:
# /data/toreport/Test2200_07_05_10_00_52/reduce/hs_err_pid2117538.log
#
# Compiler replay data is saved as:
# /data/toreport/Test2200_07_05_10_00_52/reduce/replay_pid2117538.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

Current CompileTask:
C2:1864 1462 % !   4       Test::c @ 36 (94 bytes)

Stack: [0x00007f0f0b265000,0x00007f0f0b366000],  sp=0x00007f0f0b360ac0,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x12791cf]  PhaseIdealLoop::find_safepoint(Node*, Node*, IdealLoopTree*)+0xb1f  (loopnode.cpp:711)
V  [libjvm.so+0x1297832]  PhaseIdealLoop::is_counted_loop(Node*, IdealLoopTree*&, BasicType)+0x2492
V  [libjvm.so+0x129818f]  IdealLoopTree::counted_loop(PhaseIdealLoop*)+0x6f
V  [libjvm.so+0x12981d2]  IdealLoopTree::counted_loop(PhaseIdealLoop*)+0xb2
V  [libjvm.so+0x12981d2]  IdealLoopTree::counted_loop(PhaseIdealLoop*)+0xb2
V  [libjvm.so+0x129ce47]  PhaseIdealLoop::build_and_optimize()+0x837
V  [libjvm.so+0x9e8ee0]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x390
V  [libjvm.so+0x9e1bc5]  Compile::optimize_loops(PhaseIterGVN&, LoopOptsMode)+0x75
V  [libjvm.so+0x9e4351]  Compile::Optimize()+0xe21
V  [libjvm.so+0x9e7a96]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1b06
V  [libjvm.so+0x8357a5]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1d5
V  [libjvm.so+0x9f36d8]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x928
V  [libjvm.so+0x9f4368]  CompileBroker::compiler_thread_loop()+0x478
V  [libjvm.so+0xe9cd6c]  JavaThread::thread_main_inner()+0xcc
V  [libjvm.so+0x17bd816]  Thread::call_run()+0xb6
V  [libjvm.so+0x14a5607]  thread_native_entry(Thread*)+0x127

---------- BEGIN SOURCE ----------
class Test {
  int[] b = new int[400];

  void c() {
    int e;
    float f;
    for (long d = 0; d < 5000; d++) {
      e = 1;
      while ((e += 3) < 200)
        if (d < b.length)
          for (int g = 0; g < 10000; ++g) ;
      synchronized (Test.class) {
        f = new h(e).n;
      }
    }
  }

  public static void main(String[] m) {
    Test o = new Test();
    o.c();
  }
}

class h {
  float n;
  h(float n) { this.n = n; }
}
---------- END SOURCE ----------

FREQUENCY : always



Comments
[jdk21u-fix-request] Approval Request from Satyen Subramaniam for backport of JDK-8336702: C2 compilation fails with "all memory state should have been processed" assert Motivation: Without this change the provide test code will fail to compile - this happens when converting a LongCountedLoop into a loop nest. With the fix, the intended behavior should be preserved, and the provided test code (and similar cases) will compile without issue. Risk: Medium-Low. Ran GHA Sanity Checks, local Tier 1 and 2 and new test. Touches C2 code, but change has been in tip since October 2024. Patch is clean.
12-08-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/2074 Date: 2025-08-11 19:42:11 +0000
11-08-2025

Changeset: ecc77a5b Branch: master Author: Roland Westrelin <roland@openjdk.org> Date: 2024-10-09 14:57:37 +0000 URL: https://git.openjdk.org/jdk/commit/ecc77a5b4a84c84ffa1580174872af6df3a4f6ca
09-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/21009 Date: 2024-09-16 08:34:44 +0000
16-09-2024

Roland's proposed fix for JDK-8327963 does not work, so most likely this is a different issue.
18-07-2024

Roland, if you get a chance, please have a look at this one as well. Thank you!
18-07-2024

ILW = Assert during C2 compilation, reproducible with targeted test using long counted loop but edge case, no workaround but disable compilation of affected method = HLM = P3
18-07-2024

JDK-8280320 is a red herring and not the root cause. I can reproduce this with JDK 16 as well. The assert was only added by JDK-8256655 in JDK 16 b27.
18-07-2024