JDK-8365909 : [REDO] Add a compilation timeout flag to catch long running compilations
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-08-21
  • Updated: 2025-09-01
  • Resolved: 2025-08-26
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 b13Fixed
Related Reports
Causes :  
Causes :  
Cloners :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8365910 :  
Description
We should add a compilation timeout flag to the VM to catch long running compilations. We could piggy-back on -XX:+CITime

--- a/src/hotspot/share/runtime/timerTrace.cpp
+++ b/src/hotspot/share/runtime/timerTrace.cpp
@@ -75,6 +75,9 @@ TraceTime::~TraceTime() {
   if (_accum != NULL) {
     _accum->add(_t);
   }
+  if (_t.seconds() > 3) {
+    assert(false, "Compilation timeout in phase %s", _title);
+  }
   if (!_verbose) {
     return;
   }

As part of this, or with a separate change, we might also want to improve CITime/CITimeVerbose/CITimeEach to narrow down the cause of the timout.

The disadvantage of above solution is that it would not catch endless looping compilations. For that, we would need a watcher thread (or maybe we can use an existing VM thread for that?).
Comments
Sorry about that, I thought that I managed to iron out all musl related bugs. Personally, I would prefer a PR. EDIT: I do not have easy access to Alpine, so unfortunately I can't take care of it. But I concur that struct sigevent should probably do the trick.
27-08-2025

> Personally, I would prefer a PR, which I can also take care of. Alpine build related JBS issue : https://bugs.openjdk.org/browse/JDK-8366225
27-08-2025

After this change, the Linux Alpine (fast)debug build is broken : /priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_alpine_x86_64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp: In member function 'bool CompilerThreadTimeoutLinux::init_timeout()': /priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_alpine_x86_64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp:97:3: error: 'sigevent_t' was not declared in this scope; did you mean 'sigevent'? 97 | sigevent_t sev; | ^~~~~~~~~~ | sigevent /priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_alpine_x86_64-dbg/jdk/src/hotspot/os/linux/compilerThreadTimeout_linux.cpp:98:3: error: 'sev' was not declared in this scope 98 | sev.sigev_value.sival_ptr = nullptr; | ^~~ Probably 'struct sigevent sev' should be used, this is used here https://github.com/openjdk/jdk/blob/aaff9dec241e4d8eebefd6beaf287582621f315c/src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp#L625 and seems to be there on Alpine too . Do you want me to create a separate JBS issue and try a PR to fix Alpine or want to backout this change because of the asserts ?
27-08-2025

We see lots of asserts in our nightly tests triggered by compiler/arguments/TestCompileTaskTimeout.java , I opened JDK-8366222 . This might be related to this change.
27-08-2025

Changeset: aae13af0 Branch: master Author: Manuel Hässig <mhaessig@openjdk.org> Date: 2025-08-26 13:24:05 +0000 URL: https://git.openjdk.org/jdk/commit/aae13af04bda541a80f74adff5dbf65f44c8271a
26-08-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26882 Date: 2025-08-21 11:56:17 +0000
21-08-2025