JDK-8268184 : PhaseChaitin fails with "assert(lrg._area >= 0.0) failed: negative spill area"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11-pool,16,17,19
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2021-06-03
  • Updated: 2024-02-02
  • Resolved: 2024-02-02
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.
Other
tbdResolved
Related Reports
Blocks :  
JDK-8282467 - add extra diagnostics for JDK-8268184
Duplicate :  
JDK-8282380 - compiler/intrinsics/unsafe/AllocateUninitializedArray.java crashes intermittently in AllocateUninitializedArray::testIAE
Relates :  
JDK-8273139 - C2: assert(f <= 1 && f >= 0) failed: Incorrect frequency
Relates :  
JDK-8205574 - Loop predication "assert(f <= 1 && f >= 0) failed Incorrect frequency"
Description
The following test failed in the JDK17 CI:

java/lang/invoke/ArrayLengthTest.java

Here's a snippet from the log file:

#section:testng
----------messages:(4/231)----------
command: testng -ea -esa test.java.lang.invoke.ArrayLengthTest
reason: User specified action: run testng/othervm -ea -esa test.java.lang.invoke.ArrayLengthTest 
Mode: othervm [/othervm specified]
elapsed time (seconds): 13.754
----------configuration:(0/0)----------
----------System.out:(21/1162)*----------
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\\ifg.cpp:898
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\opto\\ifg.cpp:898), pid=30988, tid=13460
#  assert(lrg._area >= 0.0) failed: negative spill area
#
# JRE version: Java(TM) SE Runtime Environment (17.0+25) (fastdebug build 17-ea+25-LTS-2208)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-ea+25-LTS-2208, compiled mode, sharing, tiered, compressed class ptrs, g1 gc, windows-amd64)
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\scratch\\4\\hs_err_pid30988.mdmp
#
# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\scratch\\4\\hs_err_pid30988.log
#
# Compiler replay data is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_lang\\scratch\\4\\replay_pid30988.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(0/0)----------
----------rerun:(53/5474)*----------

Here's the crashing thread's stack:

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

Current thread (0x0000023460369420):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=13460, stack(0x000000a4d2f00000,0x000000a4d3000000)]


Current CompileTask:
C2:   9648 1884    b  4       java.util.IdentityHashMap::put (137 bytes)

Stack: [0x000000a4d2f00000,0x000000a4d3000000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xad5121]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
V  [jvm.dll+0xcfa865]  VMError::report+0x1005  (vmError.cpp:739)
V  [jvm.dll+0xcfc1ee]  VMError::report_and_die+0x7fe  (vmError.cpp:1549)
V  [jvm.dll+0xcfc924]  VMError::report_and_die+0x64  (vmError.cpp:1330)
V  [jvm.dll+0x4c2677]  report_vm_error+0xb7  (debug.cpp:282)
V  [jvm.dll+0x66bb97]  PhaseChaitin::build_ifg_physical+0x837  (ifg.cpp:898)
V  [jvm.dll+0x3dd103]  PhaseChaitin::Register_Allocate+0x3a3  (chaitin.cpp:451)
V  [jvm.dll+0x47972f]  Compile::Code_Gen+0x25f  (compile.cpp:2727)
V  [jvm.dll+0x47855d]  Compile::Compile+0x14ed  (compile.cpp:817)
V  [jvm.dll+0x3ae35c]  C2Compiler::compile_method+0x10c  (c2compiler.cpp:106)
V  [jvm.dll+0x49105e]  CompileBroker::invoke_compiler_on_method+0x94e  (compileBroker.cpp:2312)
V  [jvm.dll+0x48e697]  CompileBroker::compiler_thread_loop+0x2b7  (compileBroker.cpp:1986)
V  [jvm.dll+0xc8a467]  JavaThread::thread_main_inner+0x1f7  (thread.cpp:1311)
V  [jvm.dll+0xc818a4]  Thread::call_run+0x1b4  (thread.cpp:399)
V  [jvm.dll+0xad3a1e]  thread_native_entry+0xae  (os_windows.cpp:549)
C  [ucrtbase.dll+0x1fb80]
C  [KERNEL32.DLL+0x84d4]
C  [ntdll.dll+0x51781]

The test task's JVM args are:

-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:-UseCompressedOops
Comments
All of the failures that I can find (some machines and/or hs_err files are no longer available) are on AMD, not Intel, which could be a clue.
18-05-2022
I tried to reproduce this using compiler replay, even changing the rounding mode, but no luck. I did some research on floating point. Using the Kahan summation algorithm might help here, depending on what the root cause turns out to be. We also might consider using interval arithmetic.
28-02-2022
I'm not an expert on this code, but I think the assert is assuming that adding a sequence of numbers and then subtracting them will give us 0.0, but I don't think that's true. If we have big_number1+big_number2+small_number1+small_number2 and do the adds in left-to-right order, don't we have to do the subtractions in reverse order? And even if we do everything in a reversible order, I would expect the result to depend on the rounding mode.
26-02-2022
Even more on rounding and Windows: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-November/031219.html
26-02-2022
More on Windows-specific issues: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-February/013537.html
26-02-2022
See https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-February/013502.html for background on this code.
26-02-2022
We now have a failure in jdk 11 too (see JDK-8282380). We should probably change the assert to print out the bad value. I think so far this only happens on Windows. I wonder if it could be because of something platform-specific, like perhaps the default rounding mode?
25-02-2022
Here's the crashing stack for the jdk-19+9-494-tier7 sighting: serviceability/sa/ClhsdbFlags.java --------------- T H R E A D --------------- Current thread (0x00000135b142bed0): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=27348, stack(0x0000001ee1500000,0x0000001ee1600000)] Current CompileTask: C2: 22226 2854 s b sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal::setThreadIntegerRegisterSet (16 bytes) Stack: [0x0000001ee1500000,0x0000001ee1600000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xbcca11] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:235) V [jvm.dll+0xe0e48e] VMError::report+0x101e (vmError.cpp:828) V [jvm.dll+0xe0fe8e] VMError::report_and_die+0x7fe (vmError.cpp:1656) V [jvm.dll+0xe10614] VMError::report_and_die+0x64 (vmError.cpp:1437) V [jvm.dll+0x53c447] report_vm_error+0xb7 (debug.cpp:282) V [jvm.dll+0x727e06] PhaseChaitin::build_ifg_physical+0x836 (ifg.cpp:898) V [jvm.dll+0x449f51] PhaseChaitin::Register_Allocate+0x881 (chaitin.cpp:559) V [jvm.dll+0x4f1f15] Compile::Code_Gen+0x275 (compile.cpp:2813) V [jvm.dll+0x4f0cdf] Compile::Compile+0x160f (compile.cpp:843) V [jvm.dll+0x4138a5] C2Compiler::compile_method+0x145 (c2compiler.cpp:115) V [jvm.dll+0x50a216] CompileBroker::invoke_compiler_on_method+0x756 (compileBroker.cpp:2293) V [jvm.dll+0x507a06] CompileBroker::compiler_thread_loop+0x276 (compileBroker.cpp:1967) V [jvm.dll+0xd8cca7] JavaThread::thread_main_inner+0x297 (thread.cpp:1296) V [jvm.dll+0xd827f4] Thread::call_run+0x1b4 (thread.cpp:361) V [jvm.dll+0xbcb3c9] thread_native_entry+0xb9 (os_windows.cpp:544) C [ucrtbase.dll+0x1fb80] o__realloc_base+0x60 C [KERNEL32.DLL+0x84d4] BaseThreadInitThunk+0x14 C [ntdll.dll+0x51791] RtlUserThreadStart+0x21
10-02-2022