JDK-8354767 : Test crashed: assert(increase < max_live_nodes_increase_per_iteration) failed: excessive live node increase in single iteration of IGVN: 4470 (should be at most 4000)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-04-16
  • Updated: 2025-05-21
  • Resolved: 2025-05-12
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 25
25 b23Fixed
Related Reports
Causes :  
JDK-8351833 - Unexpected increase in live nodes when splitting Phis through MergeMems in PhiNode::Ideal
Relates :  
JDK-8357055 - Excessive memory Phi idealization
Description
# Failure analysis

Certain idealizations introduce more new nodes than expected when adding the new assert in the changeset for JDK-8351833. The limit checked by the new assert is too optimistic.

# Why no regression test?

Triggering the assert is difficult (highly intermittent) and the issue is benign (a too optimistic limit).

# Original description

Test: java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java	

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\sb\prod\1744719015\workspace\open\src\hotspot\share\opto\phaseX.cpp:1062), pid=31356, tid=6624
#  assert(increase < max_live_nodes_increase_per_iteration) failed: excessive live node increase in single iteration of IGVN: 4470 (should be at most 4000)
#
# JRE version: Java(TM) SE Runtime Environment (25.0+19) (fastdebug build 25-ea+19-LTS-2217)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-ea+19-LTS-2217, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0xe3e998]  PhaseIterGVN::optimize+0x5e8
#
# Core dump will be written. Default location: C:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\scratch\3\hs_err_pid31356.mdmp
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

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

Command Line: -Dtest.vm.opts=-Xmx768m -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=c:\ade\mesos\work_dir\jib-master\install\jdk\24\36\bundles\windows-x64\jdk-24_windows-x64_bin.zip\jdk-24 -Djava.io.tmpdir=c:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\tmp -XX:+CreateCoredumpOnCrash -ea -esa -XX:AOTCache=c:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\aot\jdk.aotcache -Dtest.tool.vm.opts=-J-Xmx768m -J-XX:MaxRAMPercentage=4.16667 -J-Dtest.boot.jdk=c:\ade\mesos\work_dir\jib-master\install\jdk\24\36\bundles\windows-x64\jdk-24_windows-x64_bin.zip\jdk-24 -J-Djava.io.tmpdir=c:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\tmp -J-XX:+CreateCoredumpOnCrash -J-ea -J-esa -J-XX:AOTCache=c:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\aot\jdk.aotcache -Dtest.compiler.opts= -Dtest.java.opts=-XX:+AOTClassLinking -Dtest.jdk=c:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\windows-x64-debug.jdk\jdk-25\fastdebug -Dcompile.jdk=c:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\windows-x64-debug.jdk\jdk-25\fastdebug -Dtest.timeout.factor=4.0 -Dtest.nativepath=c:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\windows-x64-debug.test\jdk\jtreg\native -Dtest.root=C:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\src.full\open\test\jdk -Dtest.name=java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java -Dtest.verbose=Verbose[p=BRIEF,f=FULL,e=FULL,t=true,m=false] -Dtest.file=C:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\src.full\open\test\jdk\java\lang\invoke\VarHandles\VarHandleTestByteArrayAsLong.java -Dtest.src=C:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\src.full\open\test\jdk\java\lang\invoke\VarHandles -Dtest.src.path=C:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\src.full\open\test\jdk\java\lang\invoke\VarHandles -Dtest.classes=C:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\classes\5\java\lang\invoke\VarHandles\VarHandleTestByteArrayAsLong.d -Dtest.class.path=C:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\classes\5\java\lang\invoke\VarHandles\VarHandleTestByteArrayAsLong.d -Dtest.class.path.prefix=C:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\classes\5\java\lang\invoke\VarHandles\VarHandleTestByteArrayAsLong.d;C:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\src.full\open\test\jdk\java\lang\invoke\VarHandles -Xmx768m -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=c:\ade\mesos\work_dir\jib-master\install\jdk\24\36\bundles\windows-x64\jdk-24_windows-x64_bin.zip\jdk-24 -Djava.io.tmpdir=c:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\tmp -XX:+CreateCoredumpOnCrash -ea -esa -XX:AOTCache=c:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\aot\jdk.aotcache -XX:+AOTClassLinking -Djava.library.path=c:\ade\mesos\work_dir\jib-master\install\jdk-25+19-2217\windows-x64-debug.test\jdk\jtreg\native -Diters=2000 -XX:CompileThresholdScaling=0.1 com.sun.javatest.regtest.agent.MainWrapper C:\sb\prod\1744758111\testoutput\test-support\jtreg_open_test_jdk_jdk_lang\java\lang\invoke\VarHandles\VarHandleTestByteArrayAsLong.d\testng.1.jta java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java false VarHandleTestByteArrayAsLong

Host: AMD EPYC 7J13 64-Core Processor                , 12 cores, 23G,  Windows Server 2019 , 64 bit Build 17763 (10.0.17763.6292)
Time: Wed Apr 16 00:11:16 2025 /GM elapsed time: 11.706486 seconds (0d 0h 0m 11s)

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

Current thread (0x000001ed51b82130):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=6624, stack(0x000000bc10b00000,0x000000bc10c00000) (1024K)]


Current CompileTask:
C2:11706 3330 %     4       VarHandleTestByteArrayAsLong::testArrayReadWrite @ 35 (1861 bytes)

Stack: [0x000000bc10b00000,0x000000bc10c00000],  sp=0x000000bc10bfb970,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xe3e998]  PhaseIterGVN::optimize+0x5e8  (phaseX.cpp:1059)
V  [jvm.dll+0x5c38f1]  Compile::Optimize+0x6e1  (compile.cpp:2404)
V  [jvm.dll+0x5c0b76]  Compile::Compile+0x1126  (compile.cpp:861)
V  [jvm.dll+0x4c6c99]  C2Compiler::compile_method+0x179  (c2compiler.cpp:144)
V  [jvm.dll+0x5df42f]  CompileBroker::invoke_compiler_on_method+0x7af  (compileBroker.cpp:2307)
V  [jvm.dll+0x5dc97b]  CompileBroker::compiler_thread_loop+0x33b  (compileBroker.cpp:1952)
V  [jvm.dll+0x9375c2]  JavaThread::thread_main_inner+0x282  (javaThread.cpp:774)
V  [jvm.dll+0x10372d4]  Thread::call_run+0x1b4  (thread.cpp:236)
V  [jvm.dll+0xdf3051]  thread_native_entry+0xe1  (os_windows.cpp:566)
C  [ucrtbase.dll+0x2268a]  (no source info available)
C  [KERNEL32.DLL+0x17ac4]  (no source info available)
C  [ntdll.dll+0x5a8c1]  (no source info available)
Comments
Changeset: 2b325416 Branch: master Author: Daniel Lundén <dlunden@openjdk.org> Date: 2025-05-12 09:02:25 +0000 URL: https://git.openjdk.org/jdk/commit/2b3254160933e8b11527f801507a9c01b90d22b0
12-05-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24960 Date: 2025-04-30 10:30:33 +0000
30-04-2025
Thanks for the input [~dnsimon]. We have a bailout when we reach MaxNodeLimit during IGVN already, and the assert that now fails ensures that we do not have any individual idealizations that add an excessive number of new nodes. I'll investigate a bit more before making a decision.
16-04-2025
Without looking into the details, is this not just a case of hitting some compiler scalability limit? If so, maybe a bailout instead of an assertion is the better solution?
16-04-2025
Thanks for reporting. I think we simply need to tweak the limit max_live_nodes_increase_per_iteration (currently NodeLimitFudgeFactor * 2, which is 4000 by default). NodeLimitFudgeFactor * 3 (= 6000 by default) is probably a good start. I do think we should keep the assert to avoid issues such as JDK-8351833 in the future.
16-04-2025
ILW = Same as JDK-8351833 = P4
16-04-2025
Regression from JDK-8351833.
16-04-2025