JDK-8320302 : compiler/arguments/TestC1Globals.java hits SIGSEGV in ContinuationEntry::set_enter_code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21,22
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-11-17
  • Updated: 2024-02-21
  • Resolved: 2024-02-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 23
23 b10Fixed
Related Reports
Relates :  
JDK-8318817 - Could not reserve enough space in CodeHeap 'profiled nmethods' (0K)
Description
If this test is run with  JTREG_TEST_THREAD_FACTORY=Virtual then 

Stack: [0x00007f3a2f729000,0x00007f3a2f829000],  sp=0x00007f3a2f826160,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xa46ee8]  ContinuationEntry::set_enter_code(CompiledMethod*, int)+0x58  (codeBlob.hpp:184)
V  [libjvm.so+0x161348e]  SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle const&, int, BasicType*, VMRegPair*, BasicType)+0x2eae  (sharedRuntime_x86_64.cpp:1745)
V  [libjvm.so+0x15f4006]  AdapterHandlerLibrary::create_native_wrapper(methodHandle const&)+0x4c6  (sharedRuntime.cpp:3095)
V  [libjvm.so+0x1228b86]  LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*)+0x226  (linkResolver.cpp:1092)
V  [libjvm.so+0x1228cd3]  LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0x73  (linkResolver.cpp:1674)
V  [libjvm.so+0x122bd78]  LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*)+0x108  (linkResolver.cpp:1633)
V  [libjvm.so+0xe6a774]  InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x304  (interpreterRuntime.cpp:846)
V  [libjvm.so+0xe6b478]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x88  (interpreterRuntime.cpp:974)
j  jdk.internal.vm.Continuation.run()V+122 java.base@22-ea
j  java.lang.VirtualThread.runContinuation()V+70 java.base@22-ea
j  java.lang.VirtualThread$$Lambda+0x00007f39ef04d0b0.run()V+4 java.base@22-ea
j  java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute()Ljava/lang/Void;+4 java.base@22-ea
j  java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute()Ljava/lang/Object;+1 java.base@22-ea
j  java.util.concurrent.ForkJoinTask$InterruptibleTask.exec()Z+51 java.base@22-ea
j  java.util.concurrent.ForkJoinTask.doExec()V+10 java.base@22-ea
j  java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;Ljava/util/concurrent/ForkJoinPool$WorkQueue;I)V+49 java.base@22-ea
j  java.util.concurrent.ForkJoinPool.scan(Ljava/util/concurrent/ForkJoinPool$WorkQueue;JI)J+271 java.base@22-ea
j  java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+68 java.base@22-ea
j  java.util.concurrent.ForkJoinWorkerThread.run()V+31 java.base@22-ea
v  ~StubRoutines::call_stub 0x00007f3a48c92d21
Comments
Changeset: 46287630 Author: Patricio Chilano Mateo <pchilanomate@openjdk.org> Date: 2024-02-12 18:55:43 +0000 URL: https://git.openjdk.org/jdk/commit/462876300103feaccc078ec8694b7d861a9ed4f3
12-02-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17455 Date: 2024-01-16 23:33:58 +0000
16-01-2024
java/foreign/TestStubAllocFailure.java seems to fail intermittently for the same reason in the loom repo (where it runs with -XX:ReservedCodeCacheSize=3M and JTREG_TEST_THREAD_FACTORY=Virtual).
16-01-2024
[~dlunden] I don't think we need to rely on NMethodSizeLimit to find these kind of issues, i.e failing to allocate something because the code cache is full. We have more direct flags to control the size of the CodeCache and of each heap individually (in case of using multiple ones): ReservedCodeCacheSize, NonNMethodCodeHeapSize, NonProfiledCodeHeapSize, ProfiledCodeHeapSize. In fact I can reproduce this same crash using these flags instead: -XX:ReservedCodeCacheSize=260008192 -XX:NonNMethodCodeHeapSize=260000000. If NMethodSizeLimit should be bounded based on other settings/flags then I don't see anything wrong with enforcing that.
01-12-2023
Hi [~pchilanomate]. I added TestC1Globals in JDK-8318817 and am now working on JDK-8320682 (another issue exposed by the addition of TestC1Globals). We are debating whether or not to set an upper limit for the NMethodSizeLimit flag, as there seems to be a number of implicit assumptions about the code heap sizes in many places (which may result in further issues in the future). Do you see a value in keeping NMethodSizeLimit unrestricted for stress-testing purposes? E.g., to find issues such as this one.
01-12-2023
Using a big value for NMethodSizeLimit causes the CodeHeap initialization code to assign almost all space in the CodeCache for the NonNMethod CodeHeap, leaving only 4kB of space for the MethodProfiled and MethodNonProfiled each. By the time we try to create the enterSpecial nmethod, first in the MethodNonProfiled heap and then in the MethodProfiled heap, both have run out of space already. The problem is that we don't check the return value from nmethod::new_native_nmethod() when creating this Continuation intrinsics assuming creation will always succeed so we crash later when trying to dereference from it. The new test added by JDK-8318817 was already crashing even without the changes in that fix. So I guess there are two options here. We can exit the vm with a fatal error if creation of this nmethods (enterSpecial and doYield) fail or we can throw a VirtualMachineError exception. The latter is what we do when the same allocation failure happens for method handle intrinsics: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/systemDictionary.cpp#L2012 Also maybe we might want to allow this special methods to be created in the NonNMethod space as we do with method handle intrinsics: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.hpp#L651
21-11-2023