-
Bug
-
Resolution: Duplicate
-
P5
-
17, 20
The main loop in compileMethod continuously tries to enqueue the test method for compilation without checking if the method is (still) compilable:
https://github.com/openjdk/jdk/blob/e7795851d2e02389e63950fef939084b18ec4bfb/test/hotspot/jtreg/compiler/lib/ir_framework/test/AbstractTest.java#L135
It can happen that the first compilation fails (for example, due to reaching the MaxNodeLimit) and the method is marked as non-compilable at that level. The framework will still try to re-enqueue the method for compilation until TEST_COMPILATION_TIMEOUT is reached, leading to massive "WB error: failed to blocking compile at level 4 method" messages in the log and a confusing "Could not compile testMethod at level 4 after 10s" error message at the end. The problem is not that the method could not be compiled after 10s (i.e. it's not a compilation timeout) but that the method is non-compilable.
We should also re-evaluate why we even need that loop.
https://github.com/openjdk/jdk/blob/e7795851d2e02389e63950fef939084b18ec4bfb/test/hotspot/jtreg/compiler/lib/ir_framework/test/AbstractTest.java#L135
It can happen that the first compilation fails (for example, due to reaching the MaxNodeLimit) and the method is marked as non-compilable at that level. The framework will still try to re-enqueue the method for compilation until TEST_COMPILATION_TIMEOUT is reached, leading to massive "WB error: failed to blocking compile at level 4 method" messages in the log and a confusing "Could not compile testMethod at level 4 after 10s" error message at the end. The problem is not that the method could not be compiled after 10s (i.e. it's not a compilation timeout) but that the method is non-compilable.
We should also re-evaluate why we even need that loop.
- duplicates
-
JDK-8302203 IR framework should detect non-compilable test methods early
-
- Resolved
-