-
Enhancement
-
Resolution: Fixed
-
P4
-
21
-
b13
--- 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?).
- causes
-
JDK-8366875 CompileTaskTimeout should be reset for each iteration of RepeatCompilation
-
- In Progress
-
-
JDK-8366225 Linux Alpine (fast)debug build fails after JDK-8365909
-
- Resolved
-
-
JDK-8366222 TestCompileTaskTimeout causes asserts after JDK-8365909
-
- Resolved
-
- clones
-
JDK-8308094 Add a compilation timeout flag to catch long running compilations
-
- Closed
-
- relates to
-
JDK-8308103 Massive (up to ~30x) increase in C2 compilation time since JDK 17
-
- Resolved
-
-
JDK-8324205 Excessive C2 compilation time when parsing allocation of large object
-
- Open
-
-
JDK-8327247 C2 uses up to 2GB of RAM to compile complex string concat in extreme cases
-
- Resolved
-
-
JDK-8366569 Disable CompileTaskTimeout for known long-running test cases
-
- Resolved
-
- links to
-
Commit(master) openjdk/jdk/aae13af0
-
Commit(master) openjdk/jdk/c74c60fb
-
Review(master) openjdk/jdk/26023
-
Review(master) openjdk/jdk/26882