JDK-8295486 : Inconsistent constant field values observed during compilation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,19,20,21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86_64,aarch64
  • Submitted: 2022-10-18
  • Updated: 2024-02-08
  • Resolved: 2023-02-01
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
21 b08Fixed
Related Reports
Relates :  
JDK-8024042 - Add verification support for @Stable into VM
Relates :  
JDK-8294616 - CI: Improve caching of data queried from VM runtime
Description
The following test failed in the JDK20 CI:

serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java

Here's a snippet from the log file:

#section:main
----------messages:(6/331)----------
command: main -agentlib:DynamicCodeGenerated DynamicCodeGeneratedTest
reason: User specified action: run main/othervm/native -agentlib:DynamicCodeGenerated DynamicCodeGeneratedTest 
started: Tue Oct 18 04:57:40 UTC 2022
Mode: othervm [/othervm specified]
finished: Tue Oct 18 04:58:43 UTC 2022
elapsed time (seconds): 63.775
----------configuration:(0/0)----------
----------System.out:(21/1329)*----------
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\\phaseX.cpp:1751
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\\sb\\prod\\1665986525\\workspace\\open\\src\\hotspot\\share\\opto\\phaseX.cpp:1751), pid=27764, tid=6024
#  assert(t->meet(t0) == t->remove_speculative()) failed: Not monotonic
#
# JRE version: Java(TM) SE Runtime Environment (20.0+20) (fastdebug build 20-ea+20-1411)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+20-1411, compiled mode, sharing, compressed class ptrs, g1 gc, windows-amd64)
# Core dump will be written. Default location: C:\\sb\\prod\\1666068570\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_serviceability\\scratch\\2\\hs_err_pid27764.mdmp
#
# An error report file with more information is saved as:
# C:\\sb\\prod\\1666068570\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_serviceability\\scratch\\2\\hs_err_pid27764.log
#
# Compiler replay data is saved as:
# C:\\sb\\prod\\1666068570\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_serviceability\\scratch\\2\\replay_pid27764.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(0/0)----------
----------rerun:(48/6421)*----------

Here's the crashing thread's stack:

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

Current thread (0x000002685b675090):  JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=6024, stack(0x000000e8ec100000,0x000000e8ec200000)]


Current CompileTask:
C2:  57269 15000    b        java.lang.invoke.StringConcatFactory::newArray (35 bytes)

Stack: [0x000000e8ec100000,0x000000e8ec200000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xc08351]  os::win32::platform_print_native_stack+0xf1  (os_windows_x86.cpp:236)
V  [jvm.dll+0xe6ac0e]  VMError::report+0x10be  (vmError.cpp:841)
V  [jvm.dll+0xe6c704]  VMError::report_and_die+0x644  (vmError.cpp:1700)
V  [jvm.dll+0xe6ce44]  VMError::report_and_die+0x64  (vmError.cpp:1481)
V  [jvm.dll+0x57c6e7]  report_vm_error+0xb7  (debug.cpp:285)
V  [jvm.dll+0xc453f9]  PhaseCCP::analyze+0x569  (phaseX.cpp:1795)
V  [jvm.dll+0xc42d6f]  PhaseCCP::PhaseCCP+0x10f  (phaseX.cpp:1738)
V  [jvm.dll+0x511a71]  Compile::Optimize+0xc51  (compile.cpp:2396)
V  [jvm.dll+0x50ed3d]  Compile::Compile+0x148d  (compile.cpp:832)
V  [jvm.dll+0x4355d5]  C2Compiler::compile_method+0x145  (c2compiler.cpp:116)
V  [jvm.dll+0x528af4]  CompileBroker::invoke_compiler_on_method+0x884  (compileBroker.cpp:2243)
V  [jvm.dll+0x5262ed]  CompileBroker::compiler_thread_loop+0x23d  (compileBroker.cpp:1917)
V  [jvm.dll+0x7f2bd2]  JavaThread::thread_main_inner+0x282  (javaThread.cpp:700)
V  [jvm.dll+0xde5867]  Thread::call_run+0x257  (thread.cpp:229)
V  [jvm.dll+0xc06c68]  thread_native_entry+0xb8  (os_windows.cpp:547)
C  [ucrtbase.dll+0x2268a]
C  [KERNEL32.DLL+0x17974]
C  [ntdll.dll+0x5a0b1]

The failing assertion is similar to one that was fixed in jdk-20+20-1404,
but this failure happened in jdk-20+20-1411-tier7:

JDK-8293531 C2: some vectorapi tests fail assert "Not monotonic" with flag -XX:TypeProfileLevel=222
Comments
Changeset: cae577a7 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2023-02-01 11:15:35 +0000 URL: https://git.openjdk.org/jdk/commit/cae577a7102e97278f3f6880e529a68c1f7b71ab
01-02-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11861 Date: 2023-01-05 13:26:11 +0000
05-01-2023
Ah, you are right. That's probably the way to go then. Let me try mixing some null values in my test :)
23-11-2022
No, NULL value of a @Stable field signals that the field is not yet initialized.
23-11-2022
But even a null field value will be constant folded, right? So we would need to delay initialization of the field holder which is kind of tricky for a static field when we still want the load to be compiled.
23-11-2022
The only way to keep the load IMO is to delay the field initialization.
23-11-2022
Right, I'm currently just struggling with coming up with a test that delays constant folding the load up until CCP, because only there we would invoke LoadNode::Value multiple times.
23-11-2022
Yes, results of multiple initialization stores may be observed during compilation unless CI caches observed value.
23-11-2022
Thanks, Vladimir. In the meantime, I noticed as well that LoadNode::Value -> Type::make_constant_from_field loads the field value again on each invocation and I'm currently trying to write a test reproducing the failing scenario. There are at least two non-null field values involved though, as the logging I posted in a previous comment shows. I.e., the field value is already non-null at the start of PhaseCCP and is then updated to a different non-null value during CCP. Probably just because of a concurrent initialization of the stable field by multiple threads. Similar to what I described in JDK-8288970 (see also Test.java I attached there).
23-11-2022
> It looks like as if the load is constant folded to a DirectMethodHandle but the field value is update during CCP, leading to inconsistent types. I'm not sure yet how that can happen because the constant field value should be cached during compilation. I believe the problematic scenario is the following: - the first time a NULL is observed and the load stays intact; - meanwhile, Java code initializes the field with non-NULL value; - the second time an attempt is made, JIT observes a non-default value and turns the load into a constant. The immediate problem is that CI doesn't cache observed element values and reads the field/array element on every request (see Type::make_constant_from_field()/ciInstance::field_value() and Type::make_constant_from_array_element()/ciArray::element_value()).
23-11-2022
The type belongs to a load from the @Stable field OBJECT_STRINGIFIER from the StringConcatFactory: 2662 LoadN === 2521 768 1643 [[ 2525 ]] @java/lang/Class java.lang.Class {0x00000000d04ee3e0} - klass: public final synchronized 'java/lang/Class' [...] 0 (0x0000000000000000):Constant:exact+176 * [narrow], name=OBJECT_STRINGIFIER, idx=14; (does not depend only on test, pinned) Type:narrowoop: java/lang/invoke/MethodHandle:BotPTR * !jvms: java.lang.invoke.StringConcatFactory::floatStringifier @ bci:16 (line 905) java.lang.invoke.StringConcatFactory::generateMHInlineCopy @ bci:275 (line 508) It looks like as if the load is constant folded to a DirectMethodHandle but the field value is update during CCP, leading to inconsistent types. I'm not sure yet how that can happen because the constant field value should be cached during compilation.
18-11-2022
I verified that the assert also triggers without JDK-8293531, so this is unrelated.
18-11-2022
Output with -XX:+Verbose suggest that the actual issue is that t = type(n) and t0 = n->Value() point to different DirectMethodHandles: t: narrowoop: java/lang/invoke/DirectMethodHandle java.lang.invoke.DirectMethodHandle {0x00000000db71ee08} - klass: synchronized 'java/lang/invoke/DirectMethodHandle' - ---- fields (total size 5 words): - private 'customizationCount' 'B' @12 0 (0x00) - private volatile 'updateInProgress' 'Z' @13 false (0x00) - private final 'type' 'Ljava/lang/invoke/MethodType;' @16 a 'java/lang/invoke/MethodType'{0x00000000db795c10} = (Ljava/lang/Object;)Ljava/lang/String; (0xdb795c10) - final 'form' 'Ljava/lang/invoke/LambdaForm;' @20 a 'java/lang/invoke/LambdaForm'{0x00000000d037ed88} => a 'java/lang/invoke/MemberName'{0x00000000d037ee90} = {method} {0x00007f67d4316af0} 'invokeStatic' '(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in final synchronized 'java/lang/invoke/DirectMethodHandle$Holder' (0xd037ed88) - private 'asTypeCache' 'Ljava/lang/invoke/MethodHandle;' @24 NULL (0x00000000) - private 'asTypeSoftCache' 'Ljava/lang/ref/SoftReference;' @28 NULL (0x00000000) - final 'crackable' 'Z' @14 true (0x01) - final 'member' 'Ljava/lang/invoke/MemberName;' @32 a 'java/lang/invoke/MemberName'{0x00000000db71ed78} = {method} {0x00007f67d420e6b0} 'stringOf' '(Ljava/lang/Object;)Ljava/lang/String;' in final synchronized 'java/lang/StringConcatHelper' (0xdb71ed78):Constant:exact * t0: narrowoop: java/lang/invoke/DirectMethodHandle java.lang.invoke.DirectMethodHandle {0x00000000db9ad3d0} - klass: synchronized 'java/lang/invoke/DirectMethodHandle' - ---- fields (total size 5 words): - private 'customizationCount' 'B' @12 0 (0x00) - private volatile 'updateInProgress' 'Z' @13 false (0x00) - private final 'type' 'Ljava/lang/invoke/MethodType;' @16 a 'java/lang/invoke/MethodType'{0x00000000db795c10} = (Ljava/lang/Object;)Ljava/lang/String; (0xdb795c10) - final 'form' 'Ljava/lang/invoke/LambdaForm;' @20 a 'java/lang/invoke/LambdaForm'{0x00000000d037ed88} => a 'java/lang/invoke/MemberName'{0x00000000d037ee90} = {method} {0x00007f67d4316af0} 'invokeStatic' '(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in final synchronized 'java/lang/invoke/DirectMethodHandle$Holder' (0xd037ed88) - private 'asTypeCache' 'Ljava/lang/invoke/MethodHandle;' @24 NULL (0x00000000) - private 'asTypeSoftCache' 'Ljava/lang/ref/SoftReference;' @28 NULL (0x00000000) - final 'crackable' 'Z' @14 true (0x01) - final 'member' 'Ljava/lang/invoke/MemberName;' @32 a 'java/lang/invoke/MemberName'{0x00000000db9ad2a8} = {method} {0x00007f67d420e6b0} 'stringOf' '(Ljava/lang/Object;)Ljava/lang/String;' in final synchronized 'java/lang/StringConcatHelper' (0xdb9ad2a8):Constant:exact * t->meet(t0): narrowoop: java/lang/invoke/DirectMethodHandle:NotNull:exact * t->remove_speculative(): narrowoop: java/lang/invoke/DirectMethodHandle java.lang.invoke.DirectMethodHandle {0x00000000db71ee08} - klass: synchronized 'java/lang/invoke/DirectMethodHandle' - ---- fields (total size 5 words): - private 'customizationCount' 'B' @12 0 (0x00) - private volatile 'updateInProgress' 'Z' @13 false (0x00) - private final 'type' 'Ljava/lang/invoke/MethodType;' @16 a 'java/lang/invoke/MethodType'{0x00000000db795c10} = (Ljava/lang/Object;)Ljava/lang/String; (0xdb795c10) - final 'form' 'Ljava/lang/invoke/LambdaForm;' @20 a 'java/lang/invoke/LambdaForm'{0x00000000d037ed88} => a 'java/lang/invoke/MemberName'{0x00000000d037ee90} = {method} {0x00007f67d4316af0} 'invokeStatic' '(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in final synchronized 'java/lang/invoke/DirectMethodHandle$Holder' (0xd037ed88) - private 'asTypeCache' 'Ljava/lang/invoke/MethodHandle;' @24 NULL (0x00000000) - private 'asTypeSoftCache' 'Ljava/lang/ref/SoftReference;' @28 NULL (0x00000000) - final 'crackable' 'Z' @14 true (0x01) - final 'member' 'Ljava/lang/invoke/MemberName;' @32 a 'java/lang/invoke/MemberName'{0x00000000db71ed78} = {method} {0x00007f67d420e6b0} 'stringOf' '(Ljava/lang/Object;)Ljava/lang/String;' in final synchronized 'java/lang/StringConcatHelper' (0xdb71ed78):Constant:exact *
18-11-2022
This is extremely intermittent but I managed to reproduce with additional logging enabled: t: narrowoop: java/lang/invoke/DirectMethodHandle:exact * t0: narrowoop: java/lang/invoke/DirectMethodHandle:exact * t->meet(t0): narrowoop: java/lang/invoke/DirectMethodHandle:NotNull:exact * t->remove_speculative(): narrowoop: java/lang/invoke/DirectMethodHandle:exact * I'm not sure how this can happen.
18-11-2022
Updated ILW = JDK-8293531 only made the failing assert stronger so it is a debug VM only issue for the reported cases; seen couple of times but still intermittent and not locally reproducible, yet (tried with various replay files); disable compilation of affected method = MMM = P3
17-11-2022
[~jbhateja] - I've attached the hs_err_pid and replay files for five sightings: Test runtime/clinit/ClassInitBarrier.java: test-support_jtreg_open_test_hotspot_jtreg_hotspot_runtime_runtime_clinit_ClassInitBarrier_hs_err_pid4096539.log test-support_jtreg_open_test_hotspot_jtreg_hotspot_runtime_runtime_clinit_ClassInitBarrier_replay_pid4096539.log Test serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java: test-support_jtreg_open_test_hotspot_jtreg_hotspot_serviceability_serviceability_jvmti_DynamicCodeGenerated_DynamicCodeGeneratedTest_hs_err_pid27764.log test-support_jtreg_open_test_hotspot_jtreg_hotspot_serviceability_serviceability_jvmti_DynamicCodeGenerated_DynamicCodeGeneratedTest_replay_pid27764.log Test java/util/Collections/EmptyNavigableMap.java: test-support_jtreg_open_test_jdk_jdk_util_java_util_Collections_EmptyNavigableMap_hs_err_pid44102.log test-support_jtreg_open_test_jdk_jdk_util_java_util_Collections_EmptyNavigableMap_replay_pid44102.log Test sun/util/calendar/CalendarSystemDeadLockTest.java (2 sightings): test-support_jtreg_open_test_jdk_jdk_util_sun_util_calendar_CalendarSystemDeadLockTest_hs_err_pid16780.log test-support_jtreg_open_test_jdk_jdk_util_sun_util_calendar_CalendarSystemDeadLockTest_hs_err_pid38424.log test-support_jtreg_open_test_jdk_jdk_util_sun_util_calendar_CalendarSystemDeadLockTest_replay_pid16780.log test-support_jtreg_open_test_jdk_jdk_util_sun_util_calendar_CalendarSystemDeadLockTest_replay_pid38424.log
28-10-2022
Hi [~dcubed], Please upload the relevant replay and hs_err files. I am not able to reproduce the failures with -XX:-TieredCompilation -Xbatch -XX:TypeProfileLevel=222 options.
28-10-2022
Here's a log file snippet for the jdk-20+21-1485-tier4 sighting: runtime/clinit/ClassInitBarrier.java java.base/java.lang.Thread.run(Thread.java:1591) Phase: IN_PROGRESS Non-blocking actions: 68 / 68 Blocking actions: 0 / 14 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/phaseX.cpp:1751 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S48915/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6fabba54-5717-4210-8645-008c514d3801/runs/075776c2-60f8-4694-8e16-34141524c9a8/workspace/open/src/hotspot/share/opto/phaseX.cpp:1751), pid=4096539, tid=4096834 # assert(t->meet(t0) == t->remove_speculative()) failed: Not monotonic # # JRE version: Java(TM) SE Runtime Environment (20.0+21) (fastdebug build 20-ea+21-1485) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+21-1485, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x154c554] PhaseCCP::analyze()+0x254 # # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S94901/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c4633add-ae09-4266-96a8-9d401965a0d3/runs/d6b1e4d5-7858-4bdb-b77f-27dfb59f5de2/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/3/core.4096539) # # An error report file with more information is saved as: # /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S94901/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c4633add-ae09-4266-96a8-9d401965a0d3/runs/d6b1e4d5-7858-4bdb-b77f-27dfb59f5de2/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/3/hs_err_pid4096539.log Thread Thread[#33,Thread-4,5,MainThreadGroup]: Finished successfully Thread Thread[#50,Thread-21,5,MainThreadGroup]: Finished successfully Thread Thread[#35,Thread-6,5,MainThreadGroup]: Finished successfully Thread Thread[#52,Thread-23,5,MainThreadGroup]: Finished successfully Thread Thread[#53,Thread-24,5,MainThreadGroup]: Finished successfully Thread Thread[#34,Thread-5,5,MainThreadGroup]: Finished successfully Thread Thread[#55,Thread-26,5,MainThreadGroup]: Finished successfully Thread Thread[#51,Thread-22,5,MainThreadGroup]: Finished successfully Thread Thread[#41,Thread-12,5,MainThreadGroup]: Finished successfully Thread Thread[#61,Thread-32,5,MainThreadGroup]: Finished successfully Thread Thread[#32,Thread-3,5,MainThreadGroup]: Finished successfully Thread Thread[#31,Thread-2,5,MainThreadGroup]: Finished successfully Thread Thread[#54,Thread-25,5,MainThreadGroup]: Finished successfully # # Compiler replay data is saved as: # /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S94901/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c4633add-ae09-4266-96a8-9d401965a0d3/runs/d6b1e4d5-7858-4bdb-b77f-27dfb59f5de2/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/3/replay_pid4096539.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(0/0)---------- ----------rerun:(49/7336)*---------- Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x0000fffd0c2bb5c0): JavaThread "C2 CompilerThread3" daemon [_thread_in_native, id=4096834, stack(0x0000fffcd6000000,0x0000fffcd6200000)] Current CompileTask: C2: 17939 3195 b java.lang.invoke.StringConcatFactory::newArrayWithSuffix (61 bytes) Stack: [0x0000fffcd6000000,0x0000fffcd6200000], sp=0x0000fffcd61fabc0, free space=2026k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x154c554] PhaseCCP::analyze()+0x254 (phaseX.cpp:1751) V [libjvm.so+0x98be04] Compile::Optimize()+0x500 (compile.cpp:2393) V [libjvm.so+0x98dc18] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xfe8 (compile.cpp:831) V [libjvm.so+0x7b3d08] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1c4 (c2compiler.cpp:113) V [libjvm.so+0x99a554] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa34 (compileBroker.cpp:2237) V [libjvm.so+0x99adbc] CompileBroker::compiler_thread_loop()+0x3b8 (compileBroker.cpp:1916) V [libjvm.so+0xeb0de0] JavaThread::thread_main_inner()+0x21c (javaThread.cpp:699) V [libjvm.so+0x17b3078] Thread::call_run()+0xf8 (thread.cpp:224) V [libjvm.so+0x14c73d4] thread_native_entry(Thread*)+0x100 (os_linux.cpp:710) C [libpthread.so.0+0x7908] start_thread+0x188
21-10-2022
Hi [~jbhateja], can you take a look at that one?
18-10-2022
ILW = Newly changed assertion fails, single test and intermittent, use -XX:+UseCompressedOoops or disable compilation of affected method = HLM = P3
18-10-2022