JDK-8299956 : [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 21
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-01-11
  • Updated: 2023-01-12
  • Resolved: 2023-01-11
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 b05Fixed
Related Reports
Relates :  
JDK-8297487 - G1 Remark: no need to keep alive oop constants of nmethods on stack
Description
Several crashes have been observed after integration of JDK-8297487. We need to back it out.

tools/javac/tree/JavacTreeScannerTest.java 
tools/javac/modules/JavaBaseTest.java
tools/javac/launcher/SourceLauncherTest.java
tools/javac/tree/SourceDocTreeScannerTest.java
tools/javac/preview/classReaderTest/TooNewMajorVersionTest.java
tools/javac/TryWithResources/InterruptedExceptionTest.java
tools/javac/generics/inference/7086601/T7086601b.java

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (sharedRuntime.cpp:1457), pid=144752, tid=176160
#  guarantee(caller_cb != NULL && caller_cb->is_compiled()) failed: must be called from compiled method
#
# JRE version: Java(TM) SE Runtime Environment (21.0+5) (build 21-ea+5-LTS-244)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21-ea+5-LTS-244, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Core dump will be written. Default location: C:\sb\prod\1673434684\testoutput\test-support\jtreg_open_test_langtools_tier1\scratch\4_1\hs_err_pid144752.mdmp
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp

Stack: [0x000000eb52900000,0x000000eb52a00000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x6b03ea]  os::win32::platform_print_native_stack+0xca  (os_windows_x86.cpp:236)
V  [jvm.dll+0x8388ca]  VMError::report+0xc1a  (vmError.cpp:813)
V  [jvm.dll+0x83a4c5]  VMError::report_and_die+0x675  (vmError.cpp:1593)
V  [jvm.dll+0x83ab77]  VMError::report_and_die+0x47  (vmError.cpp:1352)
V  [jvm.dll+0x2791da]  report_vm_error+0x8a  (debug.cpp:286)
V  [jvm.dll+0x719829]  SharedRuntime::resolve_sub_helper+0xd9  (sharedRuntime.cpp:1457)
V  [jvm.dll+0x71931b]  SharedRuntime::resolve_helper+0x3b  (sharedRuntime.cpp:1337)
V  [jvm.dll+0x719d82]  SharedRuntime::resolve_virtual_call_C+0x32  (sharedRuntime.cpp:1698)
C  0x0000020a0f584486

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::resolve_virtual_call 0x0000020a0f584486
C  0x0000020a10c46e14
C  0x0000000320008131


# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffdeb723031, pid=17456, tid=54652
#
# JRE version: Java(TM) SE Runtime Environment (21.0+5) (build 21-ea+5-LTS-244)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21-ea+5-LTS-244, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x253031]  vframeStreamCommon::next+0x211
#
# Core dump will be written. Default location: C:\sb\prod\1673434720\testoutput\test-support\jtreg_open_test_langtools_tier1\scratch\5\hs_err_pid17456.mdmp
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp

Stack: [0x000000185e200000,0x000000185e300000],  sp=0x000000185e2fd2b0,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x253031]  vframeStreamCommon::next+0x211  (vframe.inline.hpp:103)
V  [jvm.dll+0x473df1]  JVM_GetStackAccessControlContext+0x361  (jvm.cpp:1309)
C  0x000001af8fafce81

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 748  java.security.AccessController.getStackAccessControlContext()Ljava/security/AccessControlContext; java.base@21-ea (0 bytes) @ 0x000001af8fafcdee [0x000001af8fafcda0+0x000000000000004e]
J 21075 c2 com.sun.tools.javac.file.JavacFileManager.getClassLoader(Ljavax/tools/JavaFileManager$Location;)Ljava/lang/ClassLoader; jdk.compiler@21-ea (105 bytes) @ 0x000001af90f85860 [0x000001af90f836c0+0x00000000000021a0]
j  com.sun.tools.javac.main.DelegatingJavaFileManager.getClassLoader(Ljavax/tools/JavaFileManager$Location;)Ljava/lang/ClassLoader;+6 jdk.compiler@21-ea
J 16098 c1 com.sun.tools.javac.processing.JavacProcessingEnvironment.initProcessorLoader()V jdk.compiler@21-ea (175 bytes) @ 0x000001af8a78e5ac [0x000001af8a78e0e0+0x00000000000004cc]
J 20808 c1 com.sun.tools.javac.processing.JavacProcessingEnvironment.<init>(Lcom/sun/tools/javac/util/Context;)V jdk.compiler@21-ea (391 bytes) @ 0x000001af8882ffec [0x000001af88829360+0x0000000000006c8c]
J 19317 c1 com.sun.tools.javac.processing.JavacProcessingEnvironment.instance(Lcom/sun/tools/javac/util/Context;)Lcom/sun/tools/javac/processing/JavacProcessingEnvironment; jdk.compiler@21-ea (25 bytes) @ 0x000001af88bdf93c [0x000001af88bdf560+0x00000000000003dc]
j  com.sun.tools.javac.api.BasicJavacTask.initPlugins(Ljava/util/Set;)V+148 jdk.compiler@21-ea
C  0x000001af90854a80
C  0xdcb0680820079a0b


# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffef7f72936, pid=9728, tid=35532
#
# JRE version: Java(TM) SE Runtime Environment (21.0+5) (build 21-ea+5-LTS-244)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21-ea+5-LTS-244, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x132936]  BarrierSetNMethod::supports_entry_barrier+0x6
#
# Core dump will be written. Default location: C:\sb\prod\1673434043\testoutput\test-support\jtreg_open_test_langtools_tier1\scratch\2\hs_err_pid9728.mdmp
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp

Stack: [0x0000005360800000,0x0000005360900000],  sp=0x00000053608fe6b0,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x132936]  BarrierSetNMethod::supports_entry_barrier+0x6  (barrierSetNMethod.cpp:48)
V  [jvm.dll+0x132b45]  BarrierSetNMethod::guard_value+0x15  (barrierSetNMethod_x86.cpp:189)
V  [jvm.dll+0x132884]  BarrierSetNMethod::nmethod_stub_entry_barrier+0x44  (barrierSetNMethod.cpp:170)
C  0x000001b2716986c9


# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fa4c11ed83d, pid=3880793, tid=3911017
#
# JRE version: Java(TM) SE Runtime Environment (21.0+5) (build 21-ea+5-LTS-244)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21-ea+5-LTS-244, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x52b83d]  frame::sender(RegisterMap*) const+0x1ed

Stack: [0x00007fa4916e0000,0x00007fa4917e1000],  sp=0x00007fa4917dc430,  free space=1009k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x52b83d]  frame::sender(RegisterMap*) const+0x1ed  (frame_x86.inline.hpp:244)
V  [libjvm.so+0x8d284c]  java_lang_Throwable::fill_in_stack_trace(Handle, methodHandle const&, JavaThread*)+0xb7c  (javaClasses.cpp:2695)
V  [libjvm.so+0x8d2d6f]  java_lang_Throwable::fill_in_stack_trace(Handle, methodHandle const&)+0x5f  (javaClasses.cpp:2782)
V  [libjvm.so+0x99262b]  JVM_FillInStackTrace+0xcb  (jvm.cpp:505)
C  [libjava.so+0x146e2]  Java_java_lang_Throwable_fillInStackTrace+0x12  (Throwable.c:49)
J 5571  java.lang.Throwable.fillInStackTrace(I)Ljava/lang/Throwable; java.base@21-ea (0 bytes) @ 0x00007fa4ac384fd9 [0x00007fa4ac384f20+0x00000000000000b9]
Comments
Hi Richard, I was able to reliably reproduce this by running full open/test/langtools/:tier1 with a product build on Linux x64 and Windows x64 in around 4/100 runs. Please note that it only reproduced for me with a full run of that task (*not* by only running one the failing tests). I've seen this before and it's most likely due to timing/warmup/profiling/code cache pressure differences when multiple tests are executed in the same VM. I narrowed it down to our CI build that included your change and then also manually verified by reverting the change. I can reproduce it with your change but not without. Also, the backout did help. We did not observe these issues anymore. I can still reproduce this with your change, so if you want me to run some experiments, let me know (we can follow-up by email).
12-01-2023
This [BACKOUT] was integrated in jdk-21+5-261.
11-01-2023
Here's a log file snippet from the jdk-21+5-252-tier4 sighting: tools/javac/processing/TestWarnErrorCount.java ----------stdout:(18/1320)---------- # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x0000fffc52ab5554, pid=70475, tid=82601 # # JRE version: Java(TM) SE Runtime Environment (21.0+5) (fastdebug build 21-ea+5-LTS-252) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-ea+5-LTS-252, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # C 0x0000fffc52ab5554 # # 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-S151514/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/1ab80dfd-041d-4011-8aa5-22b5b6df80f8/runs/baea33b5-2c11-496f-a204-29d6769b775e/testoutput/test-support/jtreg_open_test_langtools_tier1/scratch/2/core.70475) # # An error report file with more information is saved as: # /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S151514/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/1ab80dfd-041d-4011-8aa5-22b5b6df80f8/runs/baea33b5-2c11-496f-a204-29d6769b775e/testoutput/test-support/jtreg_open_test_langtools_tier1/scratch/2/hs_err_pid70475.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # result: Error. Agent communication error: java.io.EOFException; check console log for any additional details Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x0000fffc6066c500): JavaThread "AgentVMThread" [_thread_in_Java, id=82601, stack(0x0000fffc1ade0000,0x0000fffc1afe0000)] Stack: [0x0000fffc1ade0000,0x0000fffc1afe0000], sp=0x0000fffc1afdd4e0, free space=2037k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x0000fffc52ab5554 siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0x0000fffc52ab5554
11-01-2023
Hi Tobias, I don't see a connection between the attached crash logs and JDK-8297487. Also that change was very thoroughly tested on all platforms, fastdebug/release without any failures. I tried to reproduce with `time make test TEST=test/langtools/tools/javac` but so far without success. I checked out the original commit of JDK-8297487 for this. Can you help and explain how you reproduced the issue? Did the BACKOUT actually help at all? Thanks, Richard.
11-01-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11941 Date: 2023-01-11 11:27:43 +0000
11-01-2023
Changeset: d15285f9 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2023-01-11 12:39:50 +0000 URL: https://git.openjdk.org/jdk/commit/d15285f948c5414028790e25b4497d28775eeb54
11-01-2023