JDK-8166554 : Avoid compilation blocking in OverloadCompileQueueTest.java
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,13,14,15,16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-09-22
  • Updated: 2024-11-22
  • Resolved: 2020-09-08
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 11 JDK 16
11.0.23-oracleFixed 16 b15Fixed
Related Reports
Relates :  
JDK-8251349 - Add TestCaseImpl to OverloadCompileQueueTest.java's build dependencies
Relates :  
JDK-8069411 - OutOfMemoryError in OverloadCompileQueueTest.java
Relates :  
JDK-8255238 - OverloadCompileQueueTest still times out
Description
JDK-8071905 has two different issue:
 1st) the test fails w/ exit code 137. this was caused by JDK-8079586 (currently closed as fixed)
 2nd) the test timeouts

2nd issue is still unresolved and should be investigated. 

the test is currently (2016-09-22) quarantined, it was moved to quarantine by JDK-8071906 (2015-01-30)
Comments
Fix request [11u] I backport this for parity with 11.0.23-oracle. No risk, only a test change. Clean backport. Test passes. SAP nightly testing passed.
19-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2406 Date: 2023-12-18 07:41:49 +0000
18-12-2023
Changeset: 2cceeedf Author: Evgeny Nikitin <enikitin@openjdk.org> Committer: Aleksey Shipilev <shade@openjdk.org> Date: 2020-09-08 08:24:35 +0000 URL: https://git.openjdk.java.net/jdk/commit/2cceeedf
08-09-2020
> Being a daemon thread has nothing to do with whether the finally block gets executed. Well, as all the non-daemon threads are stopped, the VM stops (https://docs.oracle.com/javase/specs/jls/se14/html/jls-12.html#jls-12.8), daemon thread's code execution is therefore also stopped, our 'finally' block being not reached. > It looks very odd to have what appears to be a query function, WB_IsCompilationLocked, perform a notify_all on the Compilation_lock. What threads is it notifying and why? A dumb copy-paste, sorry. Decided to not add that method (will fix problems there with an additional bug): https://github.com/openjdk/jdk/pull/46
07-09-2020
Being a daemon thread has nothing to do with whether the finally block gets executed. It looks very odd to have what appears to be a query function, WB_IsCompilationLocked, perform a notify_all on the Compilation_lock. What threads is it notifying and why?
02-09-2020
The problem is caused by the thread that does 'lockUnlock'. The thread is daemon[0] => 'finally' [1] is not always executed => without 'finally' compilation remains locked in the VM => The VM gives 10 seconds[2] to stuck compilation threads before shutdown. That 10 seconds is sometimes enough to bypass the time limit, since the test uses almost all [3] the available time limit. An RFR with the fix: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039808.html ======== [0] https://hg.openjdk.java.net/jdk/jdk/file/e10f558e1df5/test/hotspot/jtreg/compiler/codecache/stress/Helper.java#l59 [1] https://hg.openjdk.java.net/jdk/jdk/file/e10f558e1df5/test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java#l116 [2] https://hg.openjdk.java.net/jdk/jdk/file/6db0cb3893c5/src/hotspot/share/runtime/vmOperations.cpp#l388 [3] https://hg.openjdk.java.net/jdk/jdk/file/e10f558e1df5/test/hotspot/jtreg/compiler/codecache/stress/CodeCacheStressRunner.java#l40
01-09-2020
[~enikitin], it would seem the problem still occurs. could you please take a look at the latest manifestation?
20-08-2020
Since this is a Tier3 test failure I'm bumping this bug from the P5 -> P4.
19-08-2020
Raised JDK-8251349 for the IOE failures. With a fix o it, I could not reproduce the timeouts. I'm going to unblock the test and close the case if no problems occur.
10-08-2020
currently, the test fails due to IOE: java.lang.Error: TESTBUG: cannot load class byte code compiler.codecache.stress.TestCaseImpl at compiler.codecache.stress.Helper.<clinit>(Helper.java:46) at compiler.codecache.stress.OverloadCompileQueueTest.<clinit>(OverloadCompileQueueTest.java:60) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:832) Caused by: java.io.IOException: Stream closed at java.base/java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:157) at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:244) at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:284) at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:343) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:106) at compiler.codecache.stress.Helper.loadClassData(Helper.java:84) at compiler.codecache.stress.Helper.<clinit>(Helper.java:44) ... 7 more STATUS:Failed.`main' threw exception: java.lang.Error: TESTBUG: cannot load class byte code compiler.codecache.stress.TestCaseImpl
17-07-2020
old ILW from JDK-8071905: I = L Timeout of a test that tests a boundary condition L = M Timeout happens sometimes W = L If the boundary condition happens in a product setting, the code cache can be increased. => P5
22-09-2016