Bug ID: JDK-8366222 TestCompileTaskTimeout causes asserts after JDK-8365909

JDK-8366222 : TestCompileTaskTimeout causes asserts after JDK-8365909

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 26

Priority: P4
Status: Resolved
Resolution: Fixed
OS: linux
CPU: generic

Submitted: 2025-08-27
Updated: 2025-08-28
Resolved: 2025-08-28

Versions (Unresolved/Resolved/Fixed)

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 26
26 masterFixed

Related Reports

Causes :

JDK-8365909 - [REDO] Add a compilation timeout flag to catch long running compilations

Description

With fastdebug binaries,  we see a lot of asserts triggered by compiler/arguments/TestCompileTaskTimeout.java .

Example :
#  Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-linux_aarch64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp:47), pid=10615, tid=10664
#  assert(false) failed: compile task 6 (java.lang.invoke.MethodHandleStatics.<clinit>()V) timed out after 1 ms

Current CompileTask:
C1:324    6    b  3       java.lang.invoke.MethodHandleStatics::<clinit> (241 bytes)

Stack: [0x0000ffff5d9b2000,0x0000ffff5dbb0000],  sp=0x0000ffff5dbac050,  free space=2024k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9b5efc]  CompilerThreadTimeoutLinux::compiler_signal_handler(int, siginfo_t*, void*)+0x1ac  (compilerThreadTimeout_linux.cpp:47)
C  [linux-vdso.so.1+0x7bc]  __kernel_rt_sigreturn+0x0
[error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-linux_aarch64-dbg/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]

Retrying call stack printing without source information...
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9b5efc]  CompilerThreadTimeoutLinux::compiler_signal_handler(int, siginfo_t*, void*)+0x1ac  (compilerThreadTimeout_linux.cpp:47)
C  [linux-vdso.so.1+0x7bc]  __kernel_rt_sigreturn+0x0
V  [libjvm.so+0x765280]  LinearScan::compute_global_live_sets()+0x390
V  [libjvm.so+0x77b980]  LinearScan::do_linear_scan()+0x40
V  [libjvm.so+0x6bf61c]  Compilation::emit_lir()+0x6d8
V  [libjvm.so+0x6c162c]  Compilation::compile_java_method()+0x21c
V  [libjvm.so+0x6c1eb4]  Compilation::compile_method()+0x224
V  [libjvm.so+0x6c24b4]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x2b0
V  [libjvm.so+0x6c40a0]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x15c
V  [libjvm.so+0x994cb8]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xaa4
V  [libjvm.so+0x995aa0]  CompileBroker::compiler_thread_loop()+0x66c
V  [libjvm.so+0xea1af8]  JavaThread::thread_main_inner()+0x104
V  [libjvm.so+0x19b14f0]  Thread::call_run()+0xac
V  [libjvm.so+0x14f3224]  thread_native_entry(Thread*)+0x130
C  [libpthread.so.0+0x875c]  start_thread+0x18c

Comments

Changeset: 8f864fd5 Branch: master Author: Manuel Hässig <mhaessig@openjdk.org> Date: 2025-08-28 12:48:29 +0000 URL: https://git.openjdk.org/jdk/commit/8f864fd5637762153f26af5121cabdf21e1ad798
28-08-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26963 Date: 2025-08-27 15:02:18 +0000
27-08-2025
> So in the end, as [~mhaessig] mentioned, it seems that 200 ms is just still too low and should be increased. We see no failures in opt/product (but the test has @requires vm.debug so it is not executed there) in our Linux tests envs, but not for fastdebug. Btw. we do not test slowdebug, this should be considered too .
27-08-2025
So in the end, as [~mhaessig] mentioned, it seems that 200 ms is just still too low and should be increased.
27-08-2025
Right, the hs_err files for the 1 ms failures are expected though, while the test assumes that the VM that it spawns should not fail for the 200 ms runs.
27-08-2025
For completeness, here is the stack trace and assert message of one of those 200ms asserts ; (btw with an "error occurred during error reporting") . # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_aarch64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp:47), pid=985228, tid=985277 # assert(false) failed: compile task 551 (java.lang.invoke.LambdaForm$Kind.<clinit>()V) timed out after 200 ms # # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.sapmachine.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.sapmachine.jdk, compiled mode, sharing, tiered, compressed oops, compact obj headers, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x9b5efc] CompilerThreadTimeoutLinux::compiler_signal_handler(int, siginfo_t, void)+0x1ac # --------------- T H R E A D --------------- Current thread (0x0000e4b8bc25a380): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=985277, stack(0x0000e4b892808000,0x0000e4b892a06000) (2040K)] Current CompileTask: C2:6181 551 b 4 java.lang.invoke.LambdaForm$Kind::<clinit> (942 bytes) Stack: [0x0000e4b892808000,0x0000e4b892a06000], sp=0x0000e4b892a000a0, free space=2016k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x9b5efc] CompilerThreadTimeoutLinux::compiler_signal_handler(int, siginfo_t, void)+0x1ac (compilerThreadTimeout_linux.cpp:47) C [linux-vdso.so.1+0x8f8] __kernel_rt_sigreturn+0x0 [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_aarch64-dbg/jdk/src/hotspot/share/utilities/elfFile.cpp:536)] Retrying call stack printing without source information... Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x9b5efc] CompilerThreadTimeoutLinux::compiler_signal_handler(int, siginfo_t, void)+0x1ac (compilerThreadTimeout_linux.cpp:47) C [linux-vdso.so.1+0x8f8] __kernel_rt_sigreturn+0x0 V [libjvm.so+0x653658] BarrierSetC2::compute_liveness_at_stubs() const+0x9c8 V [libjvm.so+0xbe559c] G1BarrierSetC2::late_barrier_analysis() const+0x1c V [libjvm.so+0x150c6d8] PhaseOutput::perform_mach_node_analysis()+0x78 V [libjvm.so+0x151dbc0] PhaseOutput::Output()+0xa50 V [libjvm.so+0x98224c] Compile::Code_Gen()+0x7bc V [libjvm.so+0x986228] Compile::Compile(ciEnv, ciMethod, int, Options, DirectiveSet)+0x1758 V [libjvm.so+0x7c769c] C2Compiler::compile_method(ciEnv, ciMethod, int, bool, DirectiveSet)+0x2c8 V [libjvm.so+0x994cb8] CompileBroker::invoke_compiler_on_method(CompileTask)+0xaa4 V [libjvm.so+0x995aa0] CompileBroker::compiler_thread_loop()+0x66c V [libjvm.so+0xea1af8] JavaThread::thread_main_inner()+0x104 V [libjvm.so+0x19b14f0] Thread::call_run()+0xac V [libjvm.so+0x14f3224] thread_native_entry(Thread)+0x130 C [libc.so.6+0x8595c]
27-08-2025
We have hserr files which indeed show 1 ms : # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_x86_64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp:47), pid=22772, tid=22868 # assert(false) failed: compile task 4 (java.lang.Class.desiredAssertionStatus()Z) timed out after 1 ms and also hserr files with 200 ms : # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_x86_64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp:47), pid=24182, tid=24218 # assert(false) failed: compile task 1234 (java.lang.classfile.Opcode.<clinit>()V) timed out after 200 ms So maybe some of those are expected (and are just uploaded for completeness) and some are not expected. Looking at the jtr , the assert with 200 ms is shown; so without knowing the details of your tests, I guess the 1ms hserrs are the 'good' (expected) ones.
27-08-2025
[~mbaesken] But the error you posted in the description says: # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-linux_aarch64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp:47), pid=10615, tid=10664 # assert(false) failed: compile task 6 (java.lang.invoke.MethodHandleStatics.<clinit>()V) timed out after 1 ms And the 1ms cases should fail. Is it the wrong output?
27-08-2025
ILW = Test fails (probably test bug), single test, no workaround = MLH = P4
27-08-2025
[~mbaesken] Could you please attach the full jtreg log? I think the failure mode that you posted is very much expected by the test which spawns a new VM. So maybe the error code is unexpected or something? Is this on Alpine Linux? Because we don't see it in our CI. Paging [~mhaessig]
27-08-2025
We have at the end of the log (please check the attached file) : stderr: [] exitValue = 134 java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [134] at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522) at compiler.arguments.TestCompileTaskTimeout.main(TestCompileTaskTimeout.java:53) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1474)
27-08-2025
Ah, I see. The timeout of 200ms is too slow. I'll increase it.
27-08-2025
[~mbaeksen] Does the jtreg log also contain something along the lines of "java.lang.RuntimeException: Expected to get exit value of [135], exit value is: [134]"? Because the assert in the description happens in a child VM and is entirely expected and indeed a sign that the test is working.
27-08-2025
I added a jtr from Linuxx86_64 . It shows an assert and exitValue = 134 .
27-08-2025
> Is this on Alpine Linux? Because we don't see it in our CI. No, it is on RHEL and SUSE Linux; testing is done with fastdebug binaries. We see it on ppc64, aarch64 (see above) and x86_64 .
27-08-2025